Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | logan-thornton |
View: | 215 times |
Download: | 0 times |
31. Mar. 2004 1 INF-3190: Transport Layer
Transport Layer
Foreleser: Carsten GriwodzEmail: [email protected]
31. Mar. 2004 2 INF-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
31. Mar. 2004 3 INF-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
31. Mar. 2004 4 INF-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 AddressSource address
Time to live Protocol Header checksumIdentification DM Fragment offset
Version IHL Type of service Total lengthPRE ToS
Data
OptionsSource port Destination port
Sequence numberPiggyback acknowledgement
THL
THL – TCP header lengthU: URG – urgentA: ACK – acknowledgementP: PSH – pushR: RST – resetS: SYN – syncF: FIN – finalize
F WindowSRPAUunusedChecksum Urgent pointer
Options (0 or more 32 bit words)
Sequence number andacknowledgements
Credit
31. Mar. 2004 6 INF-3190: Transport Layer
TCP Flow Control• “Sliding window” mechanism
• Sequence number space is limited• No buffers longer than 232 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
31. Mar. 2004 7 INF-3190: Transport Layer
TCP Flow ControlSender Receiver
time time
2K / SEQ=0
ACK=2048 WIN=2048
2K / SEQ=2048
ACK=4096 WIN=0
ACK=4096 WIN=2048
1K / SEQ=4096
Application doesa 2K write
Application doesa 2K write
Sender could send 2Kbut application does
only a 1K write
Sender is blocked
Sender is blocked
4K buffer
2K
Application reads 2K
2K1K
2K
31. Mar. 2004 8 INF-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
31. Mar. 2004 9 INF-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 establishmentY = buffer / 2
Senderwindow size=0
Header
Header
1 byte
Receive buffer full
Room for one byte
Receive buffer full
New byte arrives
Window update segment sent
Application reads one byte
31. Mar. 2004 10 INF-3190: Transport Layer
Transport Protocols: SCTP
31. Mar. 2004 11 INF-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
31. Mar. 2004 12 INF-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
31. Mar. 2004 13 INF-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
31. Mar. 2004 14 INF-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
31. Mar. 2004 15 INF-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 addressesassociated
with EP1
IP addressesassociatedwith EP2
Primaryaddress
Secondaryaddresses
31. Mar. 2004 16 INF-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 216 per direction)
=> in contrast to the notion of ‘stream‘ of TCP
31. Mar. 2004 17 INF-3190: Transport Layer
Association and Streams
Association
Stream A
Stream B
Stream C
1 2 3
1
21
2 3 1 2 1 12 3 1 2 1 1
231 21 1
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
31. Mar. 2004 18 INF-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
31. Mar. 2004 19 INF-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 time
INIT
INIT ACK (with cookie)
COOKIE ECHO
COOKIE ACK
State
Established
Cookie sent
Cookie wait
Closed Closed
Established
Start timer
Stop timer
Start timer
Stop timer
Generate cookie
Verify cookie
Action Action State
31. Mar. 2004 20 INF-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 1Chunk 2
Chunk n
Source portVerification Tag
Checksum
Destination port
31. Mar. 2004 21 INF-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 Type Chunk Flags Chunk Length
Chunk Value
31. Mar. 2004 22 INF-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 TagType=1 Flags: None Chunk Length
Number of outbound streamsInitial transmission sequence number
Advertised receiver credit windowNumber of inbound streams
Optional/variable lengthparameters
31. Mar. 2004 23 INF-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=0 Flags: U|B|E Chunk Length
Stream identifier S
User Data(seq n of stream S)
Payload Protocol IdentifierStream sequence number n
31. Mar. 2004 24 INF-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=0 Flags: U|B|E Chunk Length
Stream identifier S
User Data(seq n of stream S)
Payload Protocol IdentifierStream sequence number n
31. Mar. 2004 25 INF-3190: Transport Layer
Transport Protocols: DCCP
31. Mar. 2004 26 INF-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