Week 14: Dec 5


ECN: (from last time)
	routers set bit when we might otherwise drop the packet
	(possibly when queue is half full, or in lieu of RED drop)
	receivers: cwnd = cwnd/2

	Biggest advantage of ECN: the receiver discovers the congestion
	immediately, rather than waiting for the existing queue to be
	transmitted. Dropped packets are dropped upon arrival at 
	bottleneck router, but loss is not discovered until the
	queue is transmitted and three subsequent packets are sent.

TCP/Vegas 
    Why it doesn't compete well with TCP Tahoe/Reno
    Notion of "extra packets"
    Queue_use = bandwidth * (RTT - No_load_RTT)
	estimate No_load_RTT by minimum RTT
	bandwidth is easy to estimate
    Book: Diff = ExpectedRate - ActualRate

       TCP Westwood:
       Keep continuous estimate of bandwidth, BWE  (= ack rate * packet size)
       BWE * RTT_min = min window size to keep bottleneck link busy
       
       On loss, reduce cwnd to max(cwnd/2, BWE*RTT_min)
       
       Classic sawtooth, TCP Reno
       
       cwin alternates between cwin_min and cwin_max = 2*cwin_min.
       cwin_max = transit_capacity + queue_capacity
       
       If transit_capacity < cwin_min, then Reno does a pretty good job 
       keeping the bottleneck link saturated.
       
       but if transit_capacity > cwin_min, then when Reno drops to cwin_min,
       the bottleneck link is not saturated until cwin climbs to transit_capacity.
       Westwood: on loss, cwin drops to transit_capacity, a smaller reduction.
       
       What about random losses?
       
       Reno: on random loss, cwin /= 2
       Westwood: On random loss, drop back to transit_capacity.
       If cwin < transit_capacity, don't drop at all [?]
       
          
===========================================================================

Remote Procedure Calls (RPC) 
		goals for RPC: lookup, grid computing, Sun network file sharing (NFS)
		can we just use TCP?
		At-least-once semantics, idempotency, and statelessness
		client reboot v. server reboot
		Timeouts
		XDR (eXternal Data Representation) (omitted)
	6.3: BLAST, CHAN, SELECT
		Think in terms of grid computing
		Why BLAST has selective ACKs
		How CHAN implements ACKs; serialization of CHAN
		How CHAN deals with reboots, lost data: 
		Limitations of having REQ[N+1] implicitly acknowledge REPLY[N]
			CID: channel ID: at most one req outstanding per channel
				consequences if processing is slow
			MID: message ID: messages are numbered serially
				used as ack field, more or less
			BID: Boot ID: incremented each time system is booted
				client reboot
				server reboot

		Retransmit timer value


	T/TCP: (a TCP alternative to RPC)
		Implications of final ACK
		TIMEWAIT issues: old segments, lost final ACK.
		On end, connection goes into TIMEWAIT for 8*RTO
		Why this time?
		T/TCP: add new CCOUNT fields
		Allow SYN+DATA when CCOUNT is new; etc.
		Connection may be reopened by client *within* this time,
		if a new CCOUNT is used

	Serialization issues in RPC (CHAN is *synchronous*) (omit)

	NFS; implications of statelessness
	NFS stateful operations: probably omit
		rm, mkdir and server duplicate request cache
		file locking - server maintains locks, queries clients
		    if it crashes/recovers, keeps list of clients in file
		NFS v. Unix semantics for deleting open files
			client-side fix of open-file-deletion problem

================================================================
	
QoS issues:
	playback buffer
	fine-grained (per flow) v coarse-grained (per category)
	
Reservations
Integrated Services / RSVP:
Each flow can make a connection with the routers. 
Routers maintain SOFT STATE about a connection, not hard state!
Can be refreshed if lost (though with some small probability of failure)

Token bucket flow specification: token rate r bytes/sec, bucket depth B.

	Bucket fills at rate specified, does not get fuller than B
	When a packet of size S needs to be sent, S tokens are taken from B
		(B = B-S)
	B represents a "burst capacity".
	B = size of queue needed, if outbound link rate is r

Used for input control:
	if a packet arrives and the bucket is empty, it is discarded,
	or marked "noncompliant"
	
Used for shaping:
	Packets wait until there is sufficient capacity.
	This is what happens if the outbound link rate is r, 
	and B (thus) represents the queue capacity.

Simple bandwidth summation; bucket depth represents queue capacity needed
for bursts

Admission control:
	* calculation for when a flow spec can be satisfied
	* noncompliant (with bucket filter) packets can have lower priority

RESV packets: move backwards in very special way (NOT sent from receiver to sender)

PATH message contains Tspec and goes from sender to receiver.
Each router figures out reverse path.
RESV packet is sent along this reverse path by *receiver*.

Compatible w. multicast

Problem: too many reservations
And how do we decide who gets to reserve what?

Two models:
   1. Charge $ for reservations
   2. Anyone can ask for a reservation, but the answer may be "no"
      Maybe there would be a cap on size

Differentiated Services: basically just two service classes: high and low

Rules on which packets can be "premium": max rate from border router?