21.2.1 Endpoints in XCP

The end points consist of TCP source and sink agents using XCP as their congestion control mechanism. The intermediate node or router writes feedback in each packet header as the delta_throughput value, about the data capacity that may be incremented if feedback is positive and should be decreased if negative. When this packet reaches the receiver this delta_throughput value is returned to the sender in a reverse_feedback field of a congestion header in the returning packet, which is an ACK packet in case of TCP.

The sender upon receiving this reverse_feedback value adjusts its sending rate by increasing or decreasing its congestion window size as the case maybe.

The packet header that is used by XCP is implemented as a structure called hdr_xcp in ns and is defined as follows:

  double	x_;					// idealized inter-packet time
  double	rtt_;
  enum {
    XCP_DISABLED = 0,
    XCP_ENABLED,
    XCP_ACK,
  } 		xcp_enabled_;		// to indicate that the flow is XCP enabled
  int	    xcpId_;				// Sender's ID (debugging only)
  double	cwnd_;				// The current window (debugging only) 
  double	reverse_feedback_; 
  
  // --- Initialized by source and Updated by Router 
  double 	delta_throughput_;
  unsigned int controlling_hop_;// router ID (debugging only)

The xcp receiver is responsible for copying the delta_throughput value into the reverse_feedback field of the ack packets. In some cases where delayed ack is used, the receiver calculates the sum of the delta_throughput values in arriving packets for copying into the reverse_feedback field of the outgoing ack packet.

The controlling_hop_ field that carries the address of the router who has last updated the feedback is used for debugging purposes only.

In case of a packet loss in the network, TCP's Van Jacobson congestion control should most likely override XCP. However in ns this happens a little differently. With receiving of duplicate acks indicating packet loss, the cwnd gets halved and fast retransmit and fast recovery algorithms come into play. However xcp routers continue to send feedback to the source based on which the source tries to open its cwnd. So it seems to be a mish-mash of VJCC and XCP algorithms. However for most cases this issue doesnot arise as XCP router very rarely experiences a pkt drop as the queue is continuously regulated and drained by XCP. Understanding the correct behaviour of XCP in face of pkt loss is an area of current study and shall be implemented in the future.