Transport protocols and bulk file transfer

[Matthew J Zekauskas <>]

--On Thursday, December 02, 2004 4:41 PM -0600 "Lawrence D. Dunn" 
<>
 wrote:

> There is a claim that all routers on path must use XCP.
> What's the evidence for that?  Like QoS, it's probably

There is a recent Internet-Draft from Aaron Falk and Dina Katabi
that mentions a mixed environment.  In essence, it's an open question
but they talk about a few potential strategies.

<http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt>
or in HTML (from XML-RFC)
<http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-00.html>
(the 
XCP@ISI
 status is at <http://www.isi.edu/isi-xcp/> )

A clip from the draft follows.

--Matt


4.1  XCP With Non-XCP Routers

  Non-XCP routers will exist in networks before XCP becomes commonly
  deployed and we expect other non-XCP systems to continue to be in the
  network indefinitely.  Long term non-XCP network elements include any
  sort of link-level switches with queueing, e.g.  ATM switches and
  sophisticated Ethernet switches.  Even simple multiplexors are
  non-XCP queues with very little buffering.

  Sources and the network care about these non-XCP elements because any
  one of them can be a site of network congestion, and if an XCP
  endpoint is bottlenecked at one of these non-XCP elements, no router
  feedback will inform the endpoint to slow down.  If nothing is done,
  such an element will probably collapse under congestion.

  Although exactly how XCP sources will operate in this environment is
  an open issue, a current promising direction is for endpoints to run
  a traditional end-to-end congestion detection algorithm in parallel
  with the XCP algorithm and switch over to using that algorithm for
  control when congestion is detected that XCP is not controlling.  For
  example, an XCP source that detects 3 duplicate acknowledgments would
  fall back to TCP Reno behavior.

  An endpoint that is limited by its end-to-end congestion algorithm
  would indicate so to XCP routers by setting a bit in the packet
  header.  A router may process such packets differently from packets
  from endpoints that are being controlled by XCP.  For example, the
  router might allocate end-to-end controlled packets less feedback or
  not reduce its feedback pools by the full amount when assigning
  feedback to those packets.

  Though using its end-to-end algorithm to control its sending rate, an
  endpoint will also monitor the XCP feedback and if the source
  discovers that the XCP feedback would be more restrictive than the
  end-to-end control over a round trip time, the endpoint will revert
  to following XCP feedback.  XCP feedback that is more restrictive
  over a round trip time is an indication that the endpoint's
  bottleneck is once again at an XCP router and the endpoint should
  take advantage of the more precise XCP information.

  Evaluation of these algorithms is ongoing work.