transport layer

what transport layer does

• ensure reliable or fast delivery of data for a process in a host to a process in another host

• responsible for delivering data between apps running on different host

• responsible for determining which app this data is for

  • when you send an email across the world transport layer gives you confidence that email will land in their inbox regardless of chaos within network layer

• independent of physical layer

similarities and dif between data link and transport

• coordinates end to end communication for individual apps or nodes (flow control)

• but DL both nodes are connected via physical channel and transport connected via the whole internet

what is a transport entity

• software or hardware component responsible for implementing transport layer services (e.g. TCP)

• handles end to end delivery of data between apps on different systems

located in the node commonly in OS kernel

• OR can be in: user process, LIb package bound into network apps, or NIC

transport layer functions - addressing

• addressing: which app/server on a remote host to connect

  • what kind of request

  • assign a port number to an application

TSAP:

Fixed port: popular applications use the same TSAP address (permanently) on every host i.e. well known ports (port 80 for HTTP)

when services don’t have fixed port (ways to handle dynamic port:

• initial connection protocol: a special server acts as a proxy that listens on a well known port and waits for incoming client request

  • when client connects the proxy, identifies the service need

  • forwards the request to the correct app (on a different port)

  • so less used services dont have to each listen to a port

• directory server (name server)

  • listens on known TSAP e.g. port 8000

  • client will then connect here and ask which port running e.g. chat service

  • server then replies with actual IP + port

  • client disconnects from name server and connects directly to TSAP

functions - connection establishment

• send a connection request

  • e.g. type web browser will send request to server

• wait for connection accepted (CA)

• network can lose, store, and duplicate packets

  • e.g. when you lose connection info its probably not lost but stored in a router, since no ACK packet resent but router resends (duplicate)

  • 2 connections can open which is very damaging

duplicate solutions

• restrict packet lifetime

• restrict subnet design (e.g. not have such a large one)

• put a hop counter in each packet (prevent loops)

• time-stamp each packet

• need to ensure al tdpu dead as well as ACKs before using the ID (sequence #)

  • ensures old copies still floating around network are ignored and wont interfere with new connections

• wait a time after a packet has been sent

  • ensure all traces of packet + acks are gone

    T = some small multiple of the true max packet lifetime

  • e.g. if a packet can survive 60 s maybe wait 120 s

3 way handshake tomlinson

• host 1 send CR with sequence number x

• host 2 send ACK with their sequence number

• host 1 send data and ACK host 2 sequence number

handles duplicate by:

• if request lingers and arrive late it will no longer be valid

• old dupe arrives at host 2 but host doesn’t know and sends ACK

• host 1 rejects and lets 2 know it is not longer required

duplicate CR and ACK

• initial sequence number prev ack will be wrong oen so connection will be abandoned

connection release

• asymm release

  • either user or host can issue a disconnect

  • rather abrupt and can result in data loss

• sym release

  • 4 way handshake

  • both ends can initiate release independently but both side must ACK DR and complete release process

  • send both fin and ack on both sides before CR

problems with symmetric release

• not foolproof - 2 army problem

  • illustrates the challenges of achieving consensus or coordination between 2 parties over an unreliable channel

  • how do they know the final ACK is reliable? can result in one half of a connection remaining open

  • deadlock → a sends message, b receives and sends ACK, a wonders did B confirmation get through (cant trust ack), B wonders in A knows he got the message infinite confirmation needed for absolute certainty

  • use timers or acks to timers

flow control

• similar to DL by using sliding window

• use a dynamic buffer management (variable sized window) → decouple buffering from ACK

• host memory increase does not mean faster speed

  • subnets carrying capacity becomes bottleneck

• so instead use base flow control on subnet’s carrying capacity not just receiver’s buffer

multiplexing

• gathering data from multiple app processes of a sender, enveloping the data with a header, and sending them as a whole to intended receiver

• upward: multiple transport connections mapped to one network IP connection, save resource by sending several app sessions over one IP connection

• downward: one transport connections split into multiple network connections (used for load balancing, speed, and fault tolerance

crash recovery