Recap
n Networking choices:
n Broadcast network
Point-to-point networks
Network Protocols
n
n Networking issues:
n Composing networks
n Routing: name, address, route
Arvind Krishnamurthy n Route table computation
Spring 2001
Issues (Problems to solve) Issues (contd.)
n Link transmission: how do you get a packet of data from one machine n Fragmentation & reassembly
to another machine “connected” to it
n Flow control
n Routing: from one arbitrary place to another arbitrary place (fastest n Sender generating data faster than the receiver can handle
path, how do you deal with machines going down) n Feedback required from receiver to sender
n Naming: mapping names to network addresses n Congestion control
n Related to flow control; similar in many ways
n Multiplexing (how do you share resources, protocols) n There is more than the sender & receiver
n Problem gets rediscovered every once in a while!
n Reliable delivery (cannot guarantee that every packet will be delivered)
[ack, timeout, retransmit] n Presentation
n Duplicate packets n Endian-ness, floating point format
n Sequencing (process packets in the same order as it was sent; one
approach is to have only packet outstanding) n Security (authentication)
Solution: Layered Protocols Simple File Transfer
n Collection of protocols n Copy file to remote machine
n Stacked together Send( myname,
destname,
n Each solves one of the problems hostname )
name, userid
ok
block1
ack
n Protocol has three interfaces: Send( packet,
n Provides service to higher levels of the protocol stack hostname )
block2 Recv( hostname,
n Depends on some lower transport protocol
ack buffer )
n Has a peer-to-peer interface
1
Internet Protocol (IP) Addressing & Routing
n Datagram protocol (as opposed to stream protocol) n Address : two components:
n No sequencing n Network #
Host #
Stateless
n
n
n Need to fit into 32 bits
n Unreliable
n Addresses imply an unique host
n Host-to-host (not program-to-program)
n Gateways/routers have more than one address
n IP Functions:
Addressing and routing (not naming)
Routing: maintains a map of address to:
n
n
n Does not know about names
n Interface
n Understands addresses n Local address of the next hop
n Uses route information computed by some other entity n Does forwarding
n Fragmentation (controversial functionality) n Does not know the entire state of the network
Fragmentation “Time-to-live”
n If a network has a small packet size, two approaches: n Field on an IP packet header:
n Transparent approach at the network level n 8 bit header (255 secs)
n IP fragments: n Every router/gateway forwards a packet, it subtracts at least 1 tick
n Packet stays fragmented till it reaches destination n When it gets to zero, packet is trashed
n Reassembled at destination n Prevents packets from roaming around for ever
n Makes it not stateless! n Cannot reuse datagram identifiers for a while
n Destination needs to wait for all the fragments to dribble in
n IP packet headers are variable length:
n Keeps track of a partial datagram, and map of useful parts n Route that a packet takes can be recorded
Packet needs to have a datagram identifier, position, length
n
n Source routing: specify the route from the source
n IP approach: n IP limits:
Disadvantage: results in overhead for later big-packet networks
TTL limits system size?
n
n
Advantage: good for small-big-small networks
32 bits of address
n
n
n Disadvantage: no partial retransmission
n Reliability: requires to get to destination in one shot (no store and
n Disadvantage: if missing a fragment would be nice to throw away forward)
other fragments
n Speed is related to TTL (255), ID (16 bits), max. packet size (64KB)
TCP Overall Features
n Connection oriented n Reliable
Sequence numbers (per byte basis)
End-to-end reliable
n
n open n Acknowledgements
Flow controlled close
n n Timeout/retransmit
write
push n Flow control
read n “sliding window protocol”
n Purpose: pipeline communication through overlap
n Multiplexing
n Several connections to be open (sockets: host, port number)
Send packet n Connection-based: state kept at both ends
Recv packet
n Out of band data: “urgent”
2
Sequence Space Interesting Events
n Sender sequence space divided into: n New data from user:
n Sent and acknowledged n Buffer
n Sent and not acknowledged n Send if “lots” of data and in window (or push or urgent)
n Not sent and “In-window”: promise of buffer space on receiver
n Not sent and not inside the window n Data (segment) arrives at the receiver:
n Data TCP has not even seen yet (not received from user) n Check sequence number
n Receiver sequence space divided into: n Buffer data if new data, else throw away duplicates
n Data given to the user (not TCP’s responsibility any more) n Send an acknowledgement by sending back sequence numbers
n Data that has been acknowledged but not given to user n Acknowledgement sequence space should be contiguous
n Data not acknowledged n Might result in a “bunched acknowledgement”
n Rest of the window n Give data to user
Other Issues Connections
n When to retransmit? n Setup and teardown is always tricky
n No good fixed time! n Requires three-way handshakes
Must compute on the fly
n
n Setup:
n Keep a running weighted average
n Open request packet (SYN, initial sequence number)
n Give more weight to recent measurements
n Acknowledgement (SYN, own sequence number, ack number)
n Acknowledgement of the acknowledgement
n Window management? n SYN occupies 1 byte of sequence space
n Windows can decay
n Lots of scenarios:
n Receiver: only send large increments
n What if packets get lost?
n Sender: wait for large windows
n What if machines go up and down?
n Cannot reuse sequence number if there are some old live data
