Network-4-Transport Layer

• our goals
  • understand principles behind transport layer services
    • multiplexing, demultiplexing
    • reliable data transfer
    • flow control
    • congestion control
  • learn about Internet transport layer protocols
    • UDP: connectionless transport
    • TCP: connection-oriented reliable transport
    • TCP congestion control

Transport services and protocols

• provide logical communication between app processes on different hosts
• transport protocols run in end systems
  • send side: breaks app messages into segments, passes to entwork layer
  • receive side: reassembles segments into messages, passes to app layer
• more than one transport protocol abailable to apps
  • Internet: TCP and UDP

Transport vs network layer

• network layer: logical communication between hosts
• transport layer : logical communication between processes
  • relies on, enhances, network layer services

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
• service not available
  • delay guarantees
  • bandwidth guarantees

Multiplexing/demultiplexing

How demultiplexing works

• host receives IP datagrams
  • each datagram has source IP address, destination IP address
  • each datagram carries one transport-layer segment
  • each segment has source, destination port number
• host uses IP address & port numberes to direct segment to appropriate socket

Connectionless demultiplexing

• recall: created socket has host-local port #:

  • DatagramSoket mySocket1 = new DatagramSocket(12534)

• recall: when creating datagram to send into UDP socket, must specify

  • destination IP address
  • destination port #

• when host receives UDP segment

  • checks destination port # in segment

  • directs UDP segment to secket with that port #

    IP datagrams with same dest. post #, but different source IP addesses and/or source port numbers will be directed to same socket at dest

Connectionless demux: example

Connection-oriented demux

• TCP socket identified by 4-tuple
  • source IP address
  • source port number
  • dest IP address
  • dest port number
• demux
  • receiver uses all four values to direct segment to appropriate socket
• server host may support many simutaneous 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

Connection-oriented demux: example

UDP: User Datagram Protocol

• “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
• UDP use:
  • streaming multimedia apps (loss tolerant, rate sensitive)
  • DNS
  • SNMP
• reliable transfer over UDP
  • add reliability at application layer
  • application-specific error recovery

UDP: segment header

UDP checksum

• Goal: detect “errors” in transmitted segment
• sender
  • treat segment contents, including header fields, as sequence of 16-bit integers
  • checksum: additon (one’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?

Internet checksum: example

carry된 비트를 더해주고 1의 보수를 취하면 checksum

TCP

• point-to-point
  • one sender, one receiver
• reliable, in-order byte stream
  • no “messge boundaries”
• pipelined
  • TCP congestion and flow control set window size
• full duplex data
  • bi-directional data flow in same connection
  • MSS: maximum segment size
• connection-oriented
  • handshaking (exchange of control msgs) inits sender, receiver state before data exchange
• flow controlled
  • sender will not overwhelm receiver

TCP segment structure

TCP seq. numbers, ACKs

• sequnce number
  • byte stream “number” of first byte in segment’s data
• acknowledgements
  • seq # of next byte expected from other side
  • cumulative ACK
  • Q: how receiver handles out-of-order segments
    • A: TCP spec doesn’t say, up to implementor

TCP round trip time, timeout

• Q: how to set TCP timeout value?
  • longer than RTT
    • but RTT varies
  • too short: premature timeout, unneceessary retransmissions
  • too long: slow reaction to segment loss
• Q: how to estimate RTT
  • SampleRTT: measured time from segment transmission until ACK receipt
    • ignore retransmissions
  • SampleRTT will vary, want estimated RTT “smoother”
    • average several recent measurements, not just current SamplRTT

TCP: reliable data transfer

• TCP creates rdt(reliable data transfer) service on top of IP’s unreliable service
  • pipelined segments
  • cumulative acks
  • sigle retransmission timer
• retransmissions triggered by
  • time out
  • duplicate acks
• let’s initially consider simplified TCP sender
  • ignore duplicate acks
  • ignore flow control, congestion control

TCP sender events

• data rcvd from app
  • create segment with seq #
  • seq # is byte-stream number of first dta 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 ack acknowledges previously unacked segemtns
    • update what is known to be ACKed
    • start timer if there are still unacked segments

NextSeqNum은 보내야하는 Seq 번호, SendBase는 보냈지만 ACK 받지 않은 Seq 번호

TCP: retransmission scenarios

TCP ACK generation

TCP fast retransmit

• time-out period often relatively long
  • long delay before resending lost packet
• detection lost segments via duplicate ACKs
  • sender often sends many segments back-to-back
  • if segment is lost, there will likely be many duplicate ACKs
• TCP fast retransmit
  • if sender receives 3 ACKs for same data (“triple duplicate ACKs), resend unacked
    • likely that unacked segment lost, so don’t wait for timeout

TCP: flow control

• receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments
  • RcvBuffer size set via socket options (typical default is 4096 bytes)
  • many operating systems autoadjust RcvBuffer
• sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value
• guarantees receive buffer will not overflow

TCP: connection management

• before exchanging data, sender/receiver “handshake”
  • agree to establish connection (each knowing the other willing to establish connection)
  • agree on onnection parameters

Agreeing to establish a connection

• Q: will 2-way handshake always work in network?
  • variable delays
  • retransmitted messages (e.g. req_conn(x)) due to message loss
  • message reordering
  • can’t “see” other side

2-way handshake failure scenarios

TCP 3-way handshake

TCP: closing a connection

• client, server each close ther side of connection
  • send TCP segment with FIN bit = 1
• responsd to receved FINB with ACK
  • on receiving FIN, ACK can be combined with own FIN
• simultaneous FIN exchanges can be handled

client가 마지막에 2 * max segment lifetime을 대기하는 이유는

server측에서 FIN 요청을 하고 ACK를 못 받아서 다시 FIN 요청을 보낼 경우를 대비해서 대기한다

TCP congetion control

• congestion
  • informally: “toioi many sources sending too much data too fast for network to handle”
  • different from flow control!
  • manifestations
    • lost packets (buffer overflow at routers)
    • long delays (queueing in router buffers)

TCP congestion control: additive increase, multiplicative decrease

• approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs
  • additive increase: increase cwnd by 1 MSS every RTT until loss detected
  • multiplicative decrease: cut cwnd in half after loss

TCP Congestion Control: details

• sender limits transmission
  • LastByteSent - LastByteAcked <= min(cwnd, rwnd)
• cwnd is dynamic, function of perceived network congestion
• TCP sending rate
  • roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes
  • rate = cwnd / RTT (bytes/sec)

TCP Slow Start

• when connection begins, increase rate exponentially until first loss event
  • initially cwnd = 1 MSS
  • double cwnd every RTT
  • done by incrementing cwnd for every ACK received
• summary: initial rate is slow but ramps up exponentially fast

TCP: detecting, reacting to loss

• loss indicated by timeout
  • cwnd set to 1 MSS
  • window then grows exponetially (as in slow start)
• loss indicated by 3 duplicate ACKs: TCP RENO
  • dup ACKs indicate network capable of delivering som segments
  • cwnd is cut in half window then grows linearly
• TCP Tahoe always set cwnd to 1 (timeout or 3 duplicate acks)

TCP: switching from slow start to CA

• Q: when should the exponential increase switch to linear?
• A: when cwnd gets to 1/2 of its value before timeout
• Implementation
  • variable ssthresh
  • on loss event, ssthresh is set to 1/2 of cwnd just before loss event

TCP throughput

• avg. TCP throughput as function of window size, RTT?
  • ignore slow start, assuum always data to send
• W: window size (measured in bytes) where loss occurs
  • avg. window size (# in-flight bytes) is 3/4 W
  • avg. throughput is 3/4W per RTT

TCP Fairness

• fairness goal
  • if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K

Why is TCP fair?

• two competing sessions
  • additive increase gives slope of 1, as throughout inscreases
  • multiplicative decrease decreases throughput proportionally

참조

• 컴퓨터 네트워크 이미정 교수님 강의
• Computer Networking: A Top-Down Approach Featuring the Internet