[xcp] Some remarks on XCP
savoric at tkn.tu-berlin.de
Thu Nov 11 02:14:45 PST 2004
Yuri Pryadkin wrote:
> On Wednesday 10 November 2004 05:52 am, Michael Savoric wrote:
> > 1. Using an additive or delta (+/-) feedback is not an appropriate
> > mechanism. If negative
> > feedback is sent back to the sender this negative feedback is split in
> > (too) many pieces.
> > Therefore, the sender will react (too) late on this negative feedback.
> > This drawback of XCP
> > can be easily removed if absolute feedback is used. Then, also the
> > internal router calculations
> > will be cheaper. One can argue that absolute feedback will fail if
> > positive feedback is sent
> > back to the sender due to a too bursty sending behavior. But in this
> > case a pacing
> > mechanism will help the sender to spread sending packets over time.
> Would you please explain how you propose to change XCP to hand out
> absolute feedback?
It's very simple. Avoid dividing the positive and negative feedback
by H_CWND in the router (I refer to the earlier XCP papers).
Send this absolute feedback to the sender. The sender changes its CWND
to the feedback.
> > 2. The aggregated per-link feedback calculated by the efficiency
> > controller (EC) of XCP
> > in a router does not necessarily reflect the current load of a router.
> > For example, the EC of XCP uses the persistent queue length, i.e., the
> > queue length
> > that is not drain during a measurement interval, as an input variable to
> > express the
> > current filling-degree of the router queue.
> > This persistent queue length can be much lower than the current and the
> > mean queue length
> > during the same measurement interval.
> > Thus, the XCP senders loading the router do not receive accurate
> > congestion-control
> > information from the router in cases where the persistent queue length
> > is too low compared to
> > the current or mean queue length.
> My understanding is that the "persistent queue" is allowed to form to
> deal with bursty traffic. It trades off reaction time for better utilization.
> > 3. The duration of a measurement interval in the XCP controller is set
> > to the average round
> > trip time calculated over the current round trip times of all XCP
> > connections traversing this router.
> > This might result in a too long measurement interval causing a delayed
> > reaction on
> > changed load conditions in the router.
> Setting too small control interval may result in miscalculation of
> the current load, when the traffic is bursty. If you pace senders,
> as you suggest in your first paragraph, it may not be an issue.
> > I have performed simulations using XCP in gateways to modern wireless
> > access networks like
> > UMTS. And in these simulations XCP reaches a bad performance compared to
> > other
> > router congestion feedback (RCF) approaches, in particular if the
> > available capacity in the
> > wireless link decreases (downswitch). The main reason for this bad
> > performance of XCP is
> > its additive feedback. So, why not changing to an absolute feedback
> > (like the ABR feedback
> > in ATM networks)?
> I have too many questions here about the environment you're
> simulating. Are those tcp flows? Do you have non-congestive drops?
> What do you do to cwnd for those drops? Can your link capacity
> change and by how much and for how long?
> Perhaps, if you have some document describing your simulations, you
> could forward it to the list?
Unfortunately, all my XCP simulation results are currently not
public available (they are stated in project reports).
But in the next weeks I am going to publish these results-at least
in a technical report.
The simulation scenario I used consists of a single TCP / XCP connection
traversing a network path (100 ms RTT) and a UMTS (or in general: WCDMA)
In this wireless link packets can get lost. But packet losses are
locally repaired. After every 30 s I changed the capacity in the
I considered every possible capacity combinations of 64, 128, 384, 1024,
and 2048 kbps. Particularly for the highest possible downswitch
(2048 kbps -> 64 kbps). XCP cannot quickly adapt its CWND to the new
pipe capacity. This is the outcome of the delta feedback, I said before.
I compared the XCP results with TCP assisted by a WCDMA-specific AQM
or assisted by EWA, FEWA, or Enhanced TCP (ETCP). ETCP reaches
the highest throughput. The only advantage XCP has compared to the other
feedback approaches is its relatively small mean queue length and
E-Mail: savoric at ee.tu-berlin.de
Phone: (+49 30) 314-29244
Fax: (+49 30) 314-23818
Postal address: Technical University Berlin
Telecommunication Networks Group (TKN)
Einsteinufer 25, 10587 Berlin
More information about the xcp