Demultiplexing & Error Detection

Demultiplexing & Error
Detection
Lecture 10
http://www.cs.rutgers.edu/~sn624/352-S22
Srinivas Narayana
1
Quick recap of concepts
 
DASH
Video streaming over
HTTP
 
Varying 
quality
, varying
sources
, over the
duration of the video
 
Can use CDNs!
 
Tp layer
 
Endpoint
 
Endpoint
 
Transport
layer
 
Network
layer
 
TCP
 
UDP
Demultiplexing Packets
 
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
 
IP addr 1
 
IP addr 2
 
socket()
 
Ports
 
Denotes an
attachment point
with the network.
 
Each IP address
comes with a full
copy of its own
ports.
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
IP addr 1
IP addr 2
Port 1
Port 2
Port 65535
socket()
Ports
Network
Transport
Denotes an
attachment point
with the network.
Each IP address
comes with a full
copy of its own
ports.
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
IP addr 1
IP addr 2
Port 1
Port 2
Port 65535
socket()
Ports
Src IP, Dst IP, 
Tp Protocol
Src port, Dst port
Denotes an
attachment point
with the network.
Each IP address
comes with a full
copy of its own
ports.
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
IP addr 1
IP addr 2
Port 1
Port 2
Port 65535
socket()
Ports
Src IP, Dst IP, 
Tp Protocol
Src port, Dst port
Connection lookup: 
The
operating system does
a lookup using these
data to determine the
right socket and app.
Denotes an
attachment point
with the network.
Each IP address
comes with a full
copy of its own
ports.
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
IP addr 1
IP addr 2
Port 1
Port 2
Port 65535
socket()
Ports
Connection lookup: 
The
operating system does
a lookup using these
data to determine the
right socket and app.
 
TCP sockets:
(src IP,  dst IP, src port, dst
port)
Socket ID
Denotes an
attachment point
with the network.
Each IP address
comes with a full
copy of its own
ports.
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
IP addr 1
IP addr 2
Port 1
Port 2
Port 44262
Port 65535
socket()
Ports
Connection lookup: 
The
operating system does
a lookup using these
data to determine the
right socket and app.
TCP sockets:
(src IP,  dst IP, src port, dst
port)
Socket ID
Denotes an
attachment point
with the network.
Each IP address
comes with a full
copy of its own
ports.
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
IP addr 1
IP addr 2
Port 1
Port 2
Port 65535
socket()
Ports
Connection lookup: 
The
operating system does
a lookup using these
data to determine the
right socket and app.
 
TCP sockets:
(src IP,  dst IP, src port, dst
port)
Socket ID
 
UDP sockets:
(dst IP, dst port)
Socket ID
Denotes an
attachment point
with the network.
Each IP address
comes with a full
copy of its own
ports.
 
Connectionless
:
the socket is
shared across
all sources!
Demultiplexing
Machine 1
Machine
Machine 1
Machine 1
IP addr 1
IP addr 2
Port 1
Port 2
Port 65535
socket()
Ports
Connection lookup: 
The
operating system does
a lookup using these
data to determine the
right socket and app.
TCP sockets
** Some caveats!
(src IP,  dst IP, src port, dst
port)
Socket ID
UDP sockets:
(dst IP, dst port)
Socket ID
Denotes an
attachment point
with the network.
Each IP address
comes with a full
copy of its own
ports.
Connectionless
:
the socket is
shared across
all sources!
TCP sockets of different types
 
Listening
 (bound but
unconnected)
 
# On server side
ss = socket(AF_INET, SOCK_STREAM)
ss.bind(serv_ip, serv_port)
ss.listen() # no accept() yet
 
Connected (
Established
)
 
# On server side
csockid, addr = ss.accept()
 
# On client side
cs.connect(serv_ip, serv_port)
 
(src IP,  dst IP, src port, dst port)
Socket
 
(
csockid NOT ss
)
TCP sockets of different types
Listening
 (bound but
unconnected)
# On server side
ss = socket(AF_INET, SOCK_STREAM)
ss.bind(serv_ip, serv_port)
ss.listen() # no accept() yet
Connected (
Established
)
# On server side
csockid, addr = ss.accept()
# On client side
cs.connect(serv_ip, serv_port)
(src IP,  dst IP, src port, dst port)
Socket
 
(
csockid NOT ss
)
(dst IP, dst port)
Socket 
(ss)
 
accept()
creates a new
socket with the
4-tuple
(established)
mapping
 
Enables 
new
 connections to be
demultiplexed correctly
 
Enables 
existing
 connections to be demultiplexed correctly
TCP demultiplexing
 
When a 
TCP
 packet comes in, the operating system:
 
Looks up table of existing connections using 4-tuple
If success, send to corresponding (established) socket
 
If fail (no table entry), look up table of listening connections using
just (dst IP, dst port)
If success, send to corresponding (listening) socket
 
If fail again (no table entry), send error to client
Connection refused
UDP demultiplexing
 
When a 
UDP
 packet comes in, the operating system:
 
Looks up table of listening UDP sockets using 
(dst IP, dst port)
If success, send packet to corresponding socket
There are no established UDP sockets; they’re all “unconnected”
 
If fail (no table entry), send error to client
Port unreachable
Listing sockets and connections
List all sockets with 
ss
Create and observe UDP sockets with 
iperf
Observe a TCP listening socket with 
iperf
 (or your own
server!)
User Datagram Protocol
 
 
Best effort service.
 UDP
segments may be:
Lost
Delivered out of order to app
UDP is 
connectionless
Each UDP segment handled
independently
 of others (i.e. no
“memory” across packets)
Suitable for one-off req/resp
E.g., DNS uses UDP
Also for loss-tolerant delay-
sensitive apps, e.g., video calling
 
Why are UDP’s guarantees even
okay?
Simple & low overhead
 compared
to TCP:
No delays due to connection
establishment
UDP can send data immediately
No memory for connection
state at sender & receiver
Small segment header
UDP can blast away data as
fast as desired
UDP has no “congestion control”
UDP: User Datagram Protocol 
[RFC 768]
UDP segment structure
 
Length of
segment
(UDP header + data)
application
data
(message)
source port #
dest port #
length
checksum
 
Error
detection
info
(more to
come)
UDP segment structure
application
data
(message)
source port #
dest port #
length
checksum
Source IP address
Destination IP address
Review: UDP demultiplexing
application
data
(message)
source port #
dest port #
length
checksum
Source IP address
Destination IP address
Machine 1
Machine 1
Machine 1
 
IP 1
IP 2
Port 1
Port 2
Port 44262
Port 65535
socket()
Ports
Seeing UDP packets in action
 
How to craft and send (UDP) packets?
It’s simpler than you think!
 
sudo tcpdump -i lo udp –XAvvv # observe packets
sudo scapy # tool used to send crafted packets
Example: 
send(IP(dst="127.0.0.1")/UDP(sport=1024,
dport=2048)/"hello world”, iface="lo")
See other fields of UDP using 
UDP().fields_desc
Scapy can send and receive crafted packets!
However, it requires sudo (superuser privileges)
 
 
Error Detection
 
Why error detection?
 
Network provides best effort service
UDP is a simple and low overhead transport
Data may be lost
Data may be corrupted along the way (e.g., 1 -> 0)
Data may be reordered
 
However, simple error detection is possible!
Was the data I received the same data the remote machine sent?
 
Error detection is a useful feature for all transport protocols
including TCP
Error Detection in UDP and TCP
 
Key idea: have sender compute a function over the data
Store the result in the packet
Receiver can check the function’s value in received packet
 
An analogy: you’re sending a package of goodies and want
your recipient to know if goodies were leaked along the way
 
Your idea: weigh the package; stamp the weight on the package
Have the recipient weigh the package and cross-check the weight with
the stamped value
Requirements on error detection function
 
Function must be 
easy to compute
Function must 
capture the likely changes
 to the packet
If the packet was corrupted through these likely changes, the function
value must change
Function must be 
easy to verify
 
UDP and TCP use a class of function called a 
checksum
Very common idea: used in multiple parts of networks and computer
systems
 
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 a checksum of the
received segment, 
including
the checksum in packet itself
check if the resulting
(computed) checksum is 0
NO – an error is detected
YES – 
assume 
no error
UDP & TCP’s Checksum function
 
Very similar to regular (unsigned) binary addition.
However, when adding numbers, a carryout from the most
significant bit needs to be added to the result
Example: add two 16-bit integers
 
1
  1  1  1  0  0  1  1  0  0  1  1  0  0  1  1  0
1
  1  1  0  1  0  1  0  1  0  1  0  1  0  1  0  1
 
1  1  0  1  1  1  0  1  1  1  0  1  1  1  0  1  1
 
1
  1  0  1  1  1  0  1  1  1  0  1  1  1  1  0  0
1
  0  1  0  0  0  1  0  0  0  1  0  0  0  0  1  1
 
wraparound
 
sum
 
checksum
28
Computing 1’s complement sum
From the UDP specification (RFC 768)
Checksum is the 
16-bit one's complement 
of the 
one's
complement sum
 of a 
pseudo header 
of information from the 
IP
header
, the 
UDP header
, and 
the data
, padded with zero octets
at the end (if necessary) to make a multiple of two octets.
The pseudo header conceptually prefixed to the UDP header
contains the 
source address, the destination address, the
protocol, and the UDP length.
Some observations on checksums
 
Checksums don’t detect all bit errors
Consider (x, y) vs. (x – 1, y + 1) as adjacent 16-bit values in packet
Analogy: you can’t assume the package hasn’t been meddled with if its
weight matches the one on the stamp. More smarts needed for that. 
 
    
    
 
Checksums are part of the packet; they can get corrupted too
The receiver will just declare an error if it finds an error
However, checksums don’t enable the receiver to detect 
where the error lies
or correct the error(s)
Checksum is an error detection mechanism; not a correction mechanism.
Some observations on checksums
 
Checksums are insufficient for reliable data delivery
If a packet is lost, so is its checksum
 
UDP and TCP use the same checksum function
TCP also uses the lightweight error detection capability
However, TCP has more mature mechanisms for reliable data delivery
(more to come on this)
Playing with checksums
 
Summary of UDP
UDP is a thin shim around network layer’s best-effort delivery
One-off request/response messages
Lightweight transport for loss-tolerant delay-sensitive applications
Provides basic multiplexing/demultiplexing for application
No reliability, performance, or ordering guarantees
Can do basic error detection (bit flips) using checksums
Error detection is necessary to deliver data reliably, but it is insufficient
Slide Note
Embed
Share

This lecture delves into demultiplexing and error detection within the network layers, emphasizing the concepts of TCP, UDP, varying quality streaming over HTTP, and the role of CDNs. It discusses the different ports and IP addresses involved in demultiplexing packets, highlighting their attachment points within the network structure. The connection lookup process undertaken by the operating system to match sockets with applications is also explored, offering insights into the functioning of TCP sockets and socket IDs.

  • Networking
  • Demultiplexing
  • Error Detection
  • TCP UDP
  • Network Layers

Uploaded on Feb 23, 2025 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Demultiplexing & Error Detection Lecture 10 http://www.cs.rutgers.edu/~sn624/352-S22 Srinivas Narayana 1

  2. Quick recap of concepts DASH Video streaming over HTTP Varying quality, varying sources, over the duration of the video Can use CDNs! TCP UDP Transport layer Endpoint Endpoint Network layer

  3. Demultiplexing Packets

  4. Demultiplexing Port 1 Machine 1 IP addr 1 Applications Port 2 Denotes an attachment point with the network. Transport Machine 1 Network Port 65535 Machine 1 IP addr 2 Link layer Ports Each IP address comes with a full copy of its own ports. socket() Machine

  5. Demultiplexing Port 1 Machine 1 IP addr 1 Port 2 Denotes an attachment point with the network. Transport Machine 1 Network Port 65535 Machine 1 IP addr 2 Ports Each IP address comes with a full copy of its own ports. socket() Machine

  6. Demultiplexing Port 1 Machine 1 IP addr 1 Port 2 Denotes an attachment point with the network. Src port, Dst port Machine 1 Src IP, Dst IP, Tp Protocol Port 65535 Machine 1 IP addr 2 Ports Each IP address comes with a full copy of its own ports. socket() Machine

  7. Connection lookup: The operating system does a lookup using these data to determine the right socket and app. Demultiplexing Port 1 Machine 1 IP addr 1 Port 2 Denotes an attachment point with the network. Src port, Dst port Machine 1 Src IP, Dst IP, Tp Protocol Port 65535 Machine 1 IP addr 2 Ports Each IP address comes with a full copy of its own ports. socket() Machine

  8. Connection lookup: The operating system does a lookup using these data to determine the right socket and app. TCP sockets: (src IP, dst IP, src port, dst port) Socket ID Demultiplexing Port 1 Machine 1 IP addr 1 Port 2 Denotes an attachment point with the network. Machine 1 Port 65535 Machine 1 IP addr 2 Ports Each IP address comes with a full copy of its own ports. socket() Machine

  9. Connection lookup: The operating system does a lookup using these data to determine the right socket and app. TCP sockets: (src IP, dst IP, src port, dst port) Socket ID Demultiplexing Port 1 Machine 1 IP addr 1 Port 2 Denotes an attachment point with the network. Machine 1 Port 44262 Port 65535 Machine 1 IP addr 2 Ports Each IP address comes with a full copy of its own ports. socket() Machine

  10. Connection lookup: The operating system does a lookup using these data to determine the right socket and app. TCP sockets: (src IP, dst IP, src port, dst port) Socket ID Demultiplexing Port 1 Machine 1 IP addr 1 Port 2 Denotes an attachment point with the network. Machine 1 Port 65535 Machine 1 IP addr 2 UDP sockets: (dst IP, dst port) Socket ID Connectionless: the socket is shared across all sources! Ports Each IP address comes with a full copy of its own ports. socket() Machine

  11. Connection lookup: The operating system does a lookup using these data to determine the right socket and app. TCP sockets** Some caveats! (src IP, dst IP, src port, dst port) Socket ID Demultiplexing Port 1 Machine 1 IP addr 1 Port 2 Denotes an attachment point with the network. Machine 1 Port 65535 Machine 1 IP addr 2 UDP sockets: (dst IP, dst port) Socket ID Connectionless: the socket is shared across all sources! Ports Each IP address comes with a full copy of its own ports. socket() Machine

  12. TCP sockets of different types Listening (bound but unconnected) Connected (Established) # On server side csockid, addr = ss.accept() # On server side ss = socket(AF_INET, SOCK_STREAM) # On client side ss.bind(serv_ip, serv_port) cs.connect(serv_ip, serv_port) ss.listen() # no accept() yet (src IP, dst IP, src port, dst port) Socket(csockid NOT ss)

  13. TCP sockets of different types Listening (bound but unconnected) Connected (Established) accept() creates a new socket with the 4-tuple (established) mapping # On server side csockid, addr = ss.accept() # On server side ss = socket(AF_INET, SOCK_STREAM) # On client side ss.bind(serv_ip, serv_port) cs.connect(serv_ip, serv_port) ss.listen() # no accept() yet (dst IP, dst port) Socket (ss) Enables new connections to be demultiplexed correctly (src IP, dst IP, src port, dst port) Socket(csockid NOT ss) Enables existing connections to be demultiplexed correctly

  14. TCP demultiplexing When a TCP packet comes in, the operating system: Looks up table of existing connections using 4-tuple If success, send to corresponding (established) socket If fail (no table entry), look up table of listening connections using just (dst IP, dst port) If success, send to corresponding (listening) socket If fail again (no table entry), send error to client Connection refused

  15. UDP demultiplexing When a UDP packet comes in, the operating system: Looks up table of listening UDP sockets using (dst IP, dst port) If success, send packet to corresponding socket There are no established UDP sockets; they re all unconnected If fail (no table entry), send error to client Port unreachable

  16. Listing sockets and connections List all sockets with ss Create and observe UDP sockets with iperf Observe a TCP listening socket with iperf (or your own server!)

  17. User Datagram Protocol

  18. UDP: User Datagram Protocol [RFC 768] Best effort service. UDP segments may be: Lost Delivered out of order to app UDP is connectionless Each UDP segment handled independently of others (i.e. no memory across packets) Suitable for one-off req/resp E.g., DNS uses UDP Also for loss-tolerant delay- sensitive apps, e.g., video calling Why are UDP s guarantees even okay? Simple & low overhead compared to TCP: No delays due to connection establishment UDP can send data immediately No memory for connection state at sender & receiver Small segment header UDP can blast away data as fast as desired UDP has no congestion control

  19. Length of segment UDP segment structure (UDP header + data) Error detection info (more to come) Applications 16 bits 16 bits source port # dest port # Transport checksum length Network application data (message) Link layer

  20. UDP segment structure Source IP address Destination IP address Applications source port # dest port # Transport checksum length Network application data (message) Link layer

  21. Review: UDP demultiplexing Source IP address Destination IP address Port 1 Machine 1 IP 1 Port 2 source port # dest port # checksum length Machine 1 Port 44262 Port 65535 application data (message) Machine 1 IP 2 Ports socket()

  22. Seeing UDP packets in action How to craft and send (UDP) packets? It s simpler than you think! sudo tcpdump -i lo udp XAvvv # observe packets sudo scapy # tool used to send crafted packets Example: send(IP(dst="127.0.0.1")/UDP(sport=1024, dport=2048)/"hello world , iface="lo") See other fields of UDP using UDP().fields_desc Scapy can send and receive crafted packets! However, it requires sudo (superuser privileges)

  23. Error Detection

  24. Why error detection? Network provides best effort service UDP is a simple and low overhead transport Data may be lost Data may be corrupted along the way (e.g., 1 -> 0) Data may be reordered However, simple error detection is possible! Was the data I received the same data the remote machine sent? Error detection is a useful feature for all transport protocols including TCP

  25. Error Detection in UDP and TCP Key idea: have sender compute a function over the data Store the result in the packet Receiver can check the function s value in received packet An analogy: you re sending a package of goodies and want your recipient to know if goodies were leaked along the way Your idea: weigh the package; stamp the weight on the package Have the recipient weigh the package and cross-check the weight with the stamped value

  26. Requirements on error detection function Function must be easy to compute Function must capture the likely changes to the packet If the packet was corrupted through these likely changes, the function value must change Function must be easy to verify UDP and TCP use a class of function called a checksum Very common idea: used in multiple parts of networks and computer systems

  27. UDP & TCPs Checksum function 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 a checksum of the received segment, including the checksum in packet itself check if the resulting (computed) checksum is 0 NO an error is detected YES assume no error

  28. Computing 1s complement sum Very similar to regular (unsigned) binary addition. However, when adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 checksum 28

  29. From the UDP specification (RFC 768) Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length.

  30. Some observations on checksums Checksums don t detect all bit errors Consider (x, y) vs. (x 1, y + 1) as adjacent 16-bit values in packet Analogy: you can t assume the package hasn t been meddled with if its weight matches the one on the stamp. More smarts needed for that. But it s a lightweight method that works well in many cases Checksums are part of the packet; they can get corrupted too The receiver will just declare an error if it finds an error However, checksums don t enable the receiver to detect where the error lies or correct the error(s) Checksum is an error detection mechanism; not a correction mechanism.

  31. Some observations on checksums Checksums are insufficient for reliable data delivery If a packet is lost, so is its checksum UDP and TCP use the same checksum function TCP also uses the lightweight error detection capability However, TCP has more mature mechanisms for reliable data delivery (more to come on this)

  32. Playing with checksums

  33. Summary of UDP UDP is a thin shim around network layer s best-effort delivery One-off request/response messages Lightweight transport for loss-tolerant delay-sensitive applications Provides basic multiplexing/demultiplexing for application No reliability, performance, or ordering guarantees Can do basic error detection (bit flips) using checksums Error detection is necessary to deliver data reliably, but it is insufficient

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#