1. 31. Mar. 20041INF-3190: Transport Layer Transport Layer Foreleser: Carsten Griwodz Email: griff@ifi.uio.nogriff@ifi.uio.no

2. 31. Mar. 2004 2INF-3190: Transport Layer Credit Mechanism Flow control Credit mechanism Buffer reservation Receiver allocates buffers dynamically for the connections Allocation depends on the actual situation Principle Sender requests required buffer amount Receiver reserves as many buffers as the actual situation permits Receiver returns ACKs and buffer-credits separately ACK: confirmation only (does not imply buffer release) CREDIT: buffer allocation Sender is blocked when all credits are used up

3. 31. Mar. 2004 3INF-3190: Transport Layer Credit Mechanism Dynamic adjustment to Buffer situation Number of open connections Type of connections high throughput: many buffers low throughput: few buffers

4. 31. Mar. 2004 4INF-3190: Transport Layer TCP Flow Control Variable window sizes (credit mechanism) Implementation The actual window size is also transmitted with each acknowledgement Permits dynamic adjustment to existing buffer Destination Address Source address Time to liveProtocolHeader checksum IdentificationDMFragment offset VersionIHLType of serviceTotal lengthPREToS Data Options Source portDestination port Sequence number Piggyback acknowledgement THL THL – TCP header length U: URG – urgent A: ACK – acknowledgement P: PSH – push R: RST – reset S: SYN – sync F: FIN – finalize F Window SRPAUunused ChecksumUrgent pointer Options (0 or more 32 bit words) Sequence number and acknowledgements Credit

5. 31. Mar. 2004 5INF-3190: Transport Layer TCP Flow Control SEQUENCE NUMBER Number of transmitted bytes (each byte of the “message” is numbered) ACKNOWLEDGEMENT Byte number referring to the acknowledgement, specifies next byte expected FLAGS ACK AckNo is valid (if ACK=0 then no acknowledgment in segment) WINDOW SIZE Buffer size in bytes Used for variable-sized sliding window Window size field indicates #bytes sender may transmit beginning with byte acknowledged Window size = 0 is valid Bytes up to ACK-1 received but receiver does not want more data at the moment

6. 31. Mar. 2004 6INF-3190: Transport Layer TCP Flow Control “Sliding window” mechanism Sequence number space is limited No buffers longer than 2 32 possible Acknowledgement and sequence number Acknowledgments refer to byte positions Not to whole segment Sequence numbers refer to the byte position of a TCP connection Positive acknowledgement Cumulative acknowledgements Byte position in the data stream up to which all data has been received correctly Reduction of overhead More tolerable to lost acknowledgements

7. 31. Mar. 2004 7INF-3190: Transport Layer TCP Flow Control SenderReceiver time 2K / SEQ=0 ACK=2048 WIN=2048 2K / SEQ=2048 ACK=4096 WIN=0 ACK=4096 WIN=2048 1K / SEQ=4096 Application does a 2K write Application does a 2K write Sender could send 2K but application does only a 1K write Sender is blocked 4K buffer 2K Application reads 2K 2K1K 2K

8. 31. Mar. 2004 8INF-3190: Transport Layer TCP Flow Control: Special Cases Optimization for low throughput rate Problem Telnet (and ssh) connection to interactive editor reacting on every keystroke 1 character typed requires up to 162 byte Data: 20 bytes TCP header, 20 bytes IP header, 1 byte payload ACK: 20 bytes TCP header, 20 bytes IP header Echo: 20 bytes TCP header, 20 bytes IP header, 1 byte payload ACK: 20 bytes TCP header, 20 bytes IP header Approach often used Delay acknowledgment and window update by 500 ms (hoping for more data) Nagle’s algorithm, 1984 Algorithm Send first byte immediately Keep on buffering bytes until first byte has been acknowledged Then send all buffered characters in one TCP segment and start buffering again Comment Effect at e.g. X-windows: jerky pointer movements

9. 31. Mar. 2004 9INF-3190: Transport Layer TCP Flow Control: Special Cases Silly window syndrome (Clark, 1982) Problem Data on sending side arrives in large blocks But receiving side reads data at one byte at a time only Clark’s solution Prevent receiver from sending window update for 1 byte Certain amount of space must be available in order to send window update min(X,Y) X = maximum segment size announced during connection establishment Y = buffer / 2 Sender window size=0 Header 1 byte Receive buffer full Room for one byte Receive buffer full New byte arrives Window update segment sent Application reads one byte

10. 31. Mar. 200410INF-3190: Transport Layer Transport Protocols: SCTP

11. 31. Mar. 2004 11INF-3190: Transport Layer Stream Control Transmission Protocol (SCTP) Stream Control Transmission Protocol RFC2960, IETF Standards Track RFC2719, Architectual Framework for Signaling Transport SCTP Unreliable Data Mode Extension (draft-ietf-tsvwg-usctp-00.txt) Initial goal Signaling protocol for SS7 transport over IP networks Protocol of the telephony world for IP telephony Players Motorola, Cisco, Siemens, Nortel Networks, Ericsson, Telcordia, UCLA, ACIRI Goal now: A new universal transport protocol Competition or even replacement for TCP

12. 31. Mar. 2004 12INF-3190: Transport Layer SCTP Motivation TCP too limited for some applications E.g., transport signaling from PSTN networks (SS7) over IP-based networks Examples TCP: Strict order-of-transmission delivery of data with multiple streams  Partial order within a stream of multiplexed streams sufficient Stream-orientation of TCP inconvenient  Application must set record markings  Better: message-orientation TCP cannot deal with multi-homing I.e., one server with several IP addresses TCP is vulnerable to DoS attacks E.g., SYN flooding Many connect requests (SYN), but SYN/ACK response never acknowledged

13. 31. Mar. 2004 13INF-3190: Transport Layer SCTP Features Features Connection-oriented Message-oriented Fully ordered, unordered, partially ordered delivery Reliable (with extension also: unreliable, partially reliable) Multi-homed Deadlines Applications can give deadline for packet sending Once sent, delivery is guaranteed (retransmission) Delivery Sender can specify unordered delivery per packet

14. 31. Mar. 2004 14INF-3190: Transport Layer SCTP Features Reliability Sender and receiver window are computed Per stream In bytes Changed per stream as in TCP Acknowledgement using selective ACK SACK chunks Are piggybacked Contain ranges of packets Retransmission Not before 4th missing report Always before new packets Unreliable transport – V1 Proposed extension Max. number of retransmissions Specified per stream 0 is legal Ordered and unreliable is possible Unreliable transport – V2 Proposed extension Sender demands ACKs Receiver must ACK Even if packets were not received

15. 31. Mar. 2004 15INF-3190: Transport Layer Association and Streams  Connection-oriented  Concept of ‘association‘  Bi-directional  No one-way teardown of connections  Generalization of TCP-connections  Each association endpoint can have several IP addresses (multi- homing) Association Endpoint 1 Endpoint 2 IP addresses associated with EP1 IP addresses associated with EP2 Primary address Secondary addresses

16. 31. Mar. 2004 16INF-3190: Transport Layer Association and Streams Association Stream A Stream B Stream C  Connection-oriented  Concept of ‘association‘  Bi-directional  No one-way teardown of connections  Generalization of TCP-connections  Each association endpoint can have several IP addresses (multi- homing)  Each association can contain several streams (multi-streaming)  Stream: sequence of user messages to be delivered in order (up to 2 16 per direction)  => in contrast to the notion of ‘stream‘ of TCP

17. 31. Mar. 2004 17INF-3190: Transport Layer Association and Streams Association Stream A Stream B Stream C 123 1 21 231211 231211 231211 Strict order Partial order Arrival at the receiver Reliable data transfer Confirmed, no duplicates, error- free Strictly ordered delivery optional Strict order: keep order within and among streams of an association Partial order: keep order within a stream of an association Effects Strict order: data transmission stalled if one stream is stalled Partial order: transmission for non-stalled streams can continue  Example: HTTP with multiple embedded files (images)  Order of arrival of image data not relevant

18. 31. Mar. 2004 18INF-3190: Transport Layer Further SCTP Concepts Message segmentation according to path-MTU Path-MTU maximum transfer unit supported on the path between the endpoints Path-MTU discovery mechanism as specified in RFC 1191 Test whether the communication partner is alive: Heartbeats Flow control and congestion control similar to TCP (Selective Ack,...) Coexistance with TCP Security means 32-bit checksum (Adler-32, CRC-32 under discussion) 4-way handshake using cookies against DoS attacks

19. 31. Mar. 2004 19INF-3190: Transport Layer 4–way Handshake No half-open states as in TCP No state information kept at the station receiving the ‘INIT‘ message No vulnerability for SYN flooding State information established only after the third step, the ‘COOKIE‘ message To increase efficiency User data can be sent already with the ‘COOKIE‘ and ‘COOKIE ACK‘ messages time INIT INIT ACK (with cookie) COOKIE ECHO COOKIE ACK State Established Cookie sent Cookie wait Closed Established Start timer Stop timer Start timer Stop timer Generate cookie Verify cookie Action State

20. 31. Mar. 2004 20INF-3190: Transport Layer Message format Multiplexing of several user messages: Chunk Bundling Chunk: part of an SCTP packet belonging to a single stream User can request unbundled chunks Common Header Source port / destination port (2 Byte each): As in TCP or UDP Verification tag: for validation of the sender of the SCTP message Protection against blind attacks (unauthorized shutdown of association) Checksum Adler-32: currently proposed in the RFC CRC-32: proposed recently, better error detection properties for small packets Common Header … Chunk 1 Chunk 2 Chunk n Source port Verification Tag Checksum Destination port

21. 31. Mar. 2004 21INF-3190: Transport Layer Chunk Format General format of a chunk Chunk Type Type of information in the Chunk Value field E.g., type=0: payload data; type=1: INIT message,... Chunk Flags Depend on the chunk type Chunk Length Length of the chunk in bytes Including type, flags, length Chunks DATA SACK INIT ABORT SHUTDOWN HEARTBEAT ERROR ECNE CWR & responses Chunk TypeChunk FlagsChunk Length Chunk Value

22. 31. Mar. 2004 22INF-3190: Transport Layer INIT Chunk Format Initiate Tag: random number used in all subsequent messages Protect against blind attacks Advertised Receiver Credit Window Dedicated buffer space reserved for the association Number of outbound streams The sender of this INIT chunk wants to open Number of inbound streams Maximum the sender of this INIT message can support Variable-Length parameter A.o.: list of IP addresses (multi-homing!) being part of the association Initiate Tag Type=1Flags: NoneChunk Length Number of outbound streams Initial transmission sequence number Advertised receiver credit window Number of inbound streams Optional/variable length parameters

23. 31. Mar. 2004 23INF-3190: Transport Layer DATA Chunk Format Example: Format of a DATA chunk (i.e., non SCTP control message) Flags (one bit each) Unordered bit: ’1’ indicates unordered DATA chunk, ’0’ an ordered DATA chunk Beginning bit: ’1’ first fragment of a user message End bit: ’1’ last fragment of a user message Transmission Sequence Number (32 bits) => 4,300 Mio numbers Unique per stream Used for acknowledgments and duplicate recognition Acknowledgements are given per message (selective ACK)... … Transmission Sequence Number (TSN) Type=0Flags: U|B|EChunk Length Stream identifier S User Data (seq n of stream S) Payload Protocol Identifier Stream sequence number n

24. 31. Mar. 2004 24INF-3190: Transport Layer DATA Chunk Format... Stream Identifier (16 bits) Stream Sequence Number (16 bits) Unique per stream Used to assure sequenced delivery within a stream Separate acknowledgement mechanism from sequenced delivery If fragmentation is necessary, stream sequence number is the same for all fragments Payload Protocol Identifier (e.g., RTP) User Data: the actual user data to send via SCTP … Transmission Sequence Number (TSN) Type=0Flags: U|B|EChunk Length Stream identifier S User Data (seq n of stream S) Payload Protocol Identifier Stream sequence number n

25. 31. Mar. 200425INF-3190: Transport Layer Transport Protocols: DCCP

26. 31. Mar. 2004 26INF-3190: Transport Layer Datagram Congestion Control Protocol (DCCP) Datagram Congestion Control Protocol Under development http://www.ietf.org/html.charters/dccp-charter.html Transport Protocol Offers unreliable delivery Low overhead like UDP Applications using UDP can easily change to this new protocol Accommodates different congestion control Congestion Control IDs (CCIDs) Add congestion control schemes on the fly Choose a congestion control scheme TCP-friendly Rate Control (TFRC) is included Half-Connection Data Packets sent in one direction

27. 31. Mar. 2004 27INF-3190: Transport Layer Datagram Congestion Control Protocol (DCCP) Congestion control is plugable One proposal is TCP-Friendly Rate Control (TFRC) Equation-based TCP-friendly congestion control Receiver sends rate estimate and loss event history Sender uses models of SACK TCP to compute send rate Steady state TCP send rate Loss probability Number of packets ack’d by one ACK Retransmission timeout