quartz/content/notes/18-transport-layer.md

title	aliases	tags
18-transport-layer		cosc203 lecture

chapter 3

service provided by transport layer

services

• process to process communication
  • logical communication between application processes
• multi and demulti plexing
  • communication for multiple applications of the same host
• flow control
  • ensure production reate <= consuption rate
• congestion control
  • too many sender, sending too fast

protocols

• TCP transmission control protocol
• UDP user datagram protocol

actions and sender

• is passed an app layer lessage
• determines segment header fields values
• creates segment
• passes segement to IP

actions at reciever

• recieves segment from IP
• checks header values
• extract app layer message
• de multiplexes message up to application via socket

multiplexing and demultiplexing

sender: handle data from multiple sockets, add transport header reciever: user header info to deliver segments to correct socket

how it works

port number

• 16 bit integer (0, 66635)
• segment has a source and a port number
• host uses IP and port to direct segment to appropriate socket

IANA (internet assign number authority) has divded port number into three ranges

• 0-1023 well known
• 1024-49151 registered
• 49152-65535 dynamic

principle of reliable data transfer

• compexity of reliable data transfer protocol depends on character istics of unreliable channel
• sender and reciever do not know the 'state' of each other. they need to communicate via a message - ACKknowledgement

TCP

• point to point communicate
  • one sender, one reciever
• reliable, in-order byte stream
  • no message boundaries
  • each byte has a position in the stream
• full duplex data
  • bi directional data flow in the same connection
  • MSS: maximum segment size
• cumulative ACKs
  • one ack message confirms multiple segments
• connection-oriented
  • handshaking (exchange of control messages) initializes sender, reciever state before data exchange
• flow controlled
  • sender will not overwhelm reciever
• congestion controlled
  • dynamically adjust congestion window size

Structure

• sequence number - numbe assigned to the first byte of data in this segment
• ACK # - the seq # of the next expected byte; flagged as a single bit
• internet checksum - used to check for corruption
• TCP options (variable length)
• length (of TCP header)
• application data
• RST, SYN, FIN - connection management
  • syn - initiate a connection
  • fin - close a connection
• recieve window - flow control # of bytes reciever willing to accept
  • protect against buffer overflow
• C, E: congestion notification

seq number

• byte stream
• "number" of first byte in segments data
• sliding window

ack

• seq # of next bytes expected from other side
• cumulative ACK

lost and duplicated segments

• lost
  • host does not recieve data, ack is not send,
  • timeout + retransmission
  • 
  • sender sets the retransmittion timer when sending a segment
  • sender retransmits the segment iin ACK is not recieved when timer fires
• duplicated
  • host recieved data, ack is send and lost
  • data is resent, and a duplication is detected (same sequence number)

connections setup

three way handshake to set up virtual connection

• each knowing the other willing to communnicate
• agree on connection parameters (e.g., starting seq # s)

connection termination

half-close

• 

2-way handshake

• combine ack and and server fin message
• 

TCP flow control

• happens at reciever side
• we have applications, and in the kernel we have receive buffer
• incoming data is stored in recieve buffer
• applications fetch data from this buffer
• reciever advertises free buffer space in recieve window field in TCP header
• sender limits amount of in-flight data to guarantee recieve buffer will not oveflow

congestion control

"too many sources sending too much data too fast for network to handle"

consequences:

• long delay (queueing)
• packet loss (buffer overflow)

different from flow control (one sender too fast for one reciever)

AIMD - senders can increase sending rate until packet loss occurs, then decrese rate on loss event

UDP