Review of "Congestion Control for High Bandwidth-Delay Product Networks"

From: Seth Cooper (scooper@cs.washington.edu)
Date: Tue Oct 19 2004 - 23:37:15 PDT

  • Next message: Lillie Kittredge: "xcp"

            This paper describes a new transport level protocol known as XCP, the
    eXplicit Control Protocol. This protocol attempts to fix a problem with
    TCP, namely the fact that it performs poorly for flows with hight
    bandwidth and latency. XCP accomplishes this by adding headers to its
    packets to allow explicit feedback from the network. When the network
    is congested, it is able to signal an end host to slow down. It also
    allows the network to separate efficiency from fairness, possibly
    facilitating Quality of Service.
            One of the strengths of XCP is that it doesn't have TCP's slow start
    mechanism. Because feedback is explicit, XCP doesn't have to ramp up
    testing the network for congestion like TCP does. An XCP connection
    begins with the sender requesting a particular window increase from the
    receiver. If that request can be met, the connection begins at a higher
    bandwidth utilization. A TCP connection would waste the bandwidth while
    it was trying to test for congestion. TCP would do even worse on a
    network with high latency, because TCP will increases cwnd as ACKs are
    received, which occurs after a RTT has elapsed.
            Another interesting thing about XCP is that it allows the network to
    check for hosts abusing the protocol. Because the network can
    explicitly request a host to slow down, any host that the network
    believes to be sending too much can be told to slow down. If it doesn't
    respond in one RTT, then the network will know that host is abusing the
    protocol. In TCP, it would take much longer to decide if a host is not
    following the protocol, because the network would have to monitor a host
    across several RTTs.
            A weakness of XCP is that it requires support from the network. This
    is contrary to the design principle of the end to end argument.
    Although a scheme for deploying XCP across the network is presented, it
    will add responsibility to the middle of the network. That may work for
    XCP, but when another protocol comes along that also needs network
    support, the support for XCP will either have to be replaced, or will
    end up wasted.
            This paper is relevant because it is important to realize that TCP is
    not the only choice for a transport level protocol. Although it is the
    most widely deployed, it is a good idea to think of ways to overcome
    TCP's weaknesses with newer protocols, and schemes that would enable
    deployment of those new protocols.


  • Next message: Lillie Kittredge: "xcp"

    This archive was generated by hypermail 2.1.6 : Tue Oct 19 2004 - 23:37:24 PDT