Remaining internet layer topics:
	netmasks
	ipv6 addressing

Transport Layer!
	This one we interact with!
	Above it is the application layer

What do we get from the transport layer?
	Reliability (TCP but not UDP)
	Ports
	Management of the IP layer (making packets, etc)
	Duplex transmission
	Ordering
	Queueing
	
We could write a library that did all that
	And we could call it TCP...

A note about where layers are
	Network card vs. software
	"Software modem", Intel Pro100 NIC
	
UDP doesn't have to do very much
	Just send out the data

Connection-oriented Transport Layer Services
	Sequence Numbers
	Error detection and correction
	

Two-army problem
	We can't really solve it
	Ok solution:  Use timeout
	Another solution:  Application layer figures it out

Sliding window and buffer length
	We can't take an infinately old packet
	

Managing the Network Layer
	Don't overwhelm it!
	Reduce sending rate for congestion
		- Detection via packet loss
	Delay time could mean that, but also high latency
	Wifi has to do error detection for TCP

Actual Protocol Examples

UDP:
	Does very little
	Uses 64-bit header
		- source port, destination port, 16 bits each
		- length of packet, checksum
		- length limited by IP (65,515) or lower
		- IP "pseudoheader" added to checksum
			+ Can't use real header, it has time to live
			+ No support for re-sending bad packets
	Uses of UDP:
		- DNS (resolve in two packets)
		- RPC (pass-by-value no side effects)
		- RTP, layering, "real-time transfer protocol", used for VoIP
			+ No re-sending or acknowledgement
			+ Packets are numbered
			+ Header in book

TCP:
	"main workhorse of the Internet"
	Socket address:  port plus IP address
	16 bit port number
	Port numbers for common services (nmap guesses)
	byte stream, NOT message stream
	Looks a little like a pipe in UNIX
	Signaling was included, urgent data, not really used
	Every byte has a sequence number
		- 1 week to cycle on 56K, 4gb takes less time now!
	Acknowledgements carry remaining window size
	Segment header, "TCP Header" into google
	Cumulative acknowledgement
	Options:
		- Maximum segment size (at least 556 bytes)
		- Timestamp
		- SACK (for missing packets)
	Three-way handshake for connection
		- Animation on Wikipedia
		- SYN bit set
		- SYN flood
		- SYN cookie - encode information in sequence number!
	FIN, if no reply within two packet lifetimes, listening ceases
		- FIN can come earlier for one party, maybe even a lot earlier!
	Giant finite state machine drawing
		- http://www.cs.ru.nl/~ths/a3/html/h6/6-33s.jpg
		- Since we don't cover formal languages and automata...
		- Server can close the connection too.
	Sliding Window:
		- http://www.cs.ru.nl/~ths/a3/html/h6/6-34s.jpg
		- How this works
		- window probe (send one byte)
		- Buffering is ok, prioritizes throughput over latency (psh)
		- Nagle's algorithm: Only one small packet at a time
			+ TCP_NODELAY (man tcp)
		- Silly window syndrome (clark)
			+ Receiver shouldn't advertise small updates with little window space
	Retransmission TimeOut
		- smoothed round trip time
		- Basically a running average
	Congestion:
		- Only as much data as will get through easily should be sent
		- Kinda hacked
		- Acknowledgements come back at the approximate speed they arrived
		- Lots of math, summarizes to:  Adjust sending speed based on:
			+ Acknowledgement delay
			+ packet loss
		- SACK, SACK Permitted option
			+ Selective ACKnowledgements
			+ Widely deployed
	Congestion is still a problem
	Message delimiters might be nice, handled on application layer