HOMEWORK 5 FAQ

Last Revision:  945 AM, Apr 21, 2004

ERRATA
------
Problem 7e:	Should read: "Why does TCP Tahoe perform about as well
		(or poorly) as TCP Reno in handling consecutive packet
		drops."  [ Drop the last sentence. ]
Problem 8:	Use only the Solaris binary of xplot.  It is located at
		~kenw/pkg/xplot-0.90/xplot, NOT .../Solaris/xplot.
Problem 8:	hw4 should read hw5 (although one is a symbolic link to
		the other).

QUESTIONS/ANSWERS
-----------------

Problem 1
---------

Problem 2
---------

Problem 3
---------
Q3-1)	Why is the answer for part b 120 K ms and not 240 K ms ? , since
	K is the only difference between a and b.
A3-1)	Looks like a printing error in the partial solution ... it should
	be 240K msec.

Problem 4
---------

Problem 5
---------

Problem 6
---------

Problem 7
---------
Q7-1)	I would like to know whether I've understood def'n of Fast ReTx.
	Fast ReTx.
	  On recvng 3 same DUP ACK's, resend the (Dup ACK'd) frame.
	  Even if this happens for consecutive frames, resend on recvn'g 3
	   same Dup ACK's.
A7-1)	To be precise:  When get 3 duplicate ACKs asking for pkt n, retransmit
	pkt n.  Now, you are in the Fast Recovery phase (if you are using it)
	and you only transmit new pkts when cwnd gets large enough;  i.e.,
	Suppose you get 10 more duplicate ACKs asking for pkt n.  You can do
	nothing unless cwnd is large enough.

Q7-2)	I would like to know whether I've understood def'n of Fast Recovery:

	  On Recvng 3 same DUP ACK's, (ACK n)
	  ssthresh=cwnd/2
	  resend the Pkt n frame.
	  cwnd=ssthresh+3

	  try and send frames upto cwnd in the current window (if not done yet)

	  On recvng same DUP ACK'd frames (An), keep incrementing cwnd,
	  and try and send the frames untill cwnd.

	  On rcvng ACK n+1 (or higher),
	  ssthresh=cwnd
	  //stay in cong'n avoidance.

	Now if consecutive packets are lost (i.e pkt n+1 is also lost)
	and 3 DUP ACK's are rcvd for the consecutive packet, I guess fast
	recovery gets triggered once again. Is this right ?
	So if we recv. ACK n+1 3 times in the above e.g, the foll. happens
	all over again ?
	  ssthresh=cwnd/2
	  resend Pkt n+1
	  cwnd=ssthresh+3
A7-2)	In principle, yes ... BUT the 3 dupe ACKs for n+1 probably won't happen.
	More likely to happen is that you will get (maybe) 1 ACK for pkt n+1
	due to the retransmission of pkt n and nothing else will come
	(ACK depletion).  This ACK n+1 takes you out of fast recovery in
	TCP Reno.
	However, in new Reno, it does NOT take you out of fast recovery.
	Rather, new Reno interprets ACK n+1 while in fast recover as a sign
	that pkt n+1 was also dropped and therefore, the sender now
	retransmits pkt n+1 and stays in fast recovery.  In fact, in the
	tcptrace lecture Examples 4, 6, 8 and 9 show this effect.

Problem 8
---------
Q8-1)	Do I have to know anything about tcptrace to do this problem?
A8-1)	Read the xplot README file to learn how to drive the mouse.
	Look at the online tcptrace manual section labeled "Graphing"
	(www.tcptrace.org/manual/index.html) which describes examples
	of plots.  The time sequence graph is about all you need.
	"Detailed Usage/Detailed Stats" will explain the txt file.
Q8-2)	Why should traffic suddenly start flowing again after long
	idle periods?
A8-2)	The application is doing something else (e.g., reading disk
	or waiting for a reply from the application at the other end).
	Note that all bytes have been ACKed.  So, it can't be a TCP
	problem.

Problem 9
---------
 
Problem 10
----------
Q10-1) I'm doubtful as to which V we have to use for RTO calc'n ?

	loop {
	  RTTSamp_n	= f1 		   + f2
			= 40 + 0.1 * (n-1) + n%100 >= 90 ? 100.0 : 0.0;
	  E_n 		= ...
	  RTTEst_n  	= ...
	  V_n		= ...
	  VEst_n	=  ...
	}
	RTO =  RTT + 4 * V;
	Should I use  RTTEst_n for RTT? ...  And VEst_n for V?
A10-1)	Yes, RTT is the RTT estimate and V is the variability estimate.