[xcp] XCP stability problem

[Ted Faber]

On Fri, Nov 18, 2005 at 03:17:11AM +0900, Alp wrote:
> I am waiting for your reply. 

Hi.

I found some time to play with your simulations today, and you're not
seeing a simulator bug.  You're using ns correctly, and it's not doing
anything wrong as far as I can tell.

I would be careful about generalizing too much from these results,
though.  The XCP implemented in ns is not a perfect reflection of all
the thinking about XCP.  It's generated from the original sims and
tweaked some for robustness and integration, but I don't think it's a
full implementation of all the corner cases.

One of the nasty effects you're seeing is that the simulation
of XCP in ns is not programmed to deal well with packet loss.  And, by
that I mean that it doesn't deal with them at all - TCP error correction
takes over and interferes with the XCP rate control algorithm.  This is,
IMHO, the reason that the performance degredation is so catastrophic.

There are some other things going on that you probably already know, but
that others might be curious about.  This simulation of XCP uses the
length of the standing queue in bytes in its feedback calculations, but
the implementation queues packets.  The ACKs in your two-way traffic are
underrepresented in terms of the queueing term of the phi calculation.
They're 40 bytes long, but really take up 1/nbuf of the queue.  Beyond
that, this simulation doesn't count ACK packets at all in determining
the traffic load - i.e. the arrival rate.

Your discussion of the RTT and its effect on the throughput variable in
this ns simulation is correct, but I believe that this is not the
dominant feature that's causing your performance degredation.  (I
believe this because I ran your scenario through a simulation that
(correctly) just keeps track of the throughput assigned by the router
and it didn't fix anything - in fact things got worse.)

There is plenty of room to improve the simulation code in these respects
and others.  We're delighted to receive patches, and I apologize that
not everything is implemented.

I did try a few things out and they may provide some directions for you
or others:  

	* Smoothing the traffic eliminates the problem.  There are
	  standing queues from the unaccounted for ACKS, but they're
	  about 5 packets (just eyballing it).  Throughput in each
	  direction saturates the link and is very smooth.

	* Increasing the queue size by a factor of 5 gets rid of the big
	  drops in utilization and throughput - again pointing the
	  finger at the packet loss code.  There's about a 150 packet
	  standing queue in this case, with gusts somewhat higher.
	  Throughput is not as stable as in the smoothed case, but
	  considerably better than before.

	* Using the router-assigned throughput rather than recalculating
	  the throughput put into each packet based on current RTT &
	  cwnd actually makes the situation worse in the lossy case, but
	  again I believe that this is because the underlying loss
	  reaction strategy in this code is unsound.

I have a student looking at a more sane strategy for reacting to losses,
and he's had some good preliminary results that I hope to write up and
get out to the community in the near future.  (And we'll contribute that
code to the ns simulation, too.)

If you have more results or want to discuss this in more detail
(especially if I've been unclear) please don't hesitate to get back to
me on or off the list.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/xcp/attachments/20051122/c7333434/attachment.bin