[Cse461] ACK compression, TCP unfairness, and peering policy

From: Janet Davis (jlnd_at_cs.washington.edu)
Date: Wed Feb 25 2004 - 16:29:32 PST

  • Next message: Janet Davis: "[Cse461] Homework 3, Question 2 typo"

    Here's the promised information on three unrelated subjects.

    ===

    Last week, I posed a problem: What could cause ACK clocking to break?
    Suppose that the acknowledgements, nicely spaced out according to the
    bottleneck bandwidth, arrive at a full queue. Further suppose that they
    arrive during a lull in the traffic, so that they end up back-to-back in
    the queue, even though they arrived at different times. When the router
    forwards them, they will be forwarded back-to-back -- faster than the
    bottleneck bandwidth, thus breaking the ACK clock.

    A total lull in traffic isn't necessary; the link just needs to be at less
    than full capacity when the packets arrive at a non-empty queue to mess up
    the ACK spacing.

    This has been observed to happen on the Internet, and it's called ACK
    compression. You can read about it here:
    http://citeseer.nj.nec.com/mogul92observing.html

    ==

    We talked a bit about why TCP should provide proportional fairness;
    however, TCP is often not fair in the real world. There are several
    reasons for this. In particular:

    1. ACK compression and the slow start/AIMD algorithms mean that packets
    from the same flow tend to be clustered together. As a result, a FIFO
    queue overflowing typically causes many packets to be lost from the same
    flow, rather than being evenly distributed across all the flows. This is
    one of the reasons we like RED, which makes an effort to spread packet
    drops out over time.

    This could why reloading a web page makes it load faster -- if you are
    unlucky enough to have many packets dropped from your connection, then you
    have to time out and start over with slow start. If you start a new
    connection, you may be more lucky.

    2. TCP connections with a longer RTT take longer to increase their window
    size in AIMD (since the rule is increase by one packet per RTT), and are
    thus at a disadvantage. If there are many connections with very short
    RTTs on a bottleneck link, they may crowd out connections with longer
    RTTs.

    ===

    This paper describes the process of deciding whether to peer in more
    detail.

    http://citeseer.nj.nec.com/norton00internet.html

    -- 
    Janet Davis
    jlnd_at_cs.washington.edu
    http://www.cs.washington.edu/homes/jlnd/
    _______________________________________________
    Cse461 mailing list
    Cse461_at_cs.washington.edu
    http://mailman.cs.washington.edu/mailman/listinfo/cse461
    

  • Next message: Janet Davis: "[Cse461] Homework 3, Question 2 typo"

    This archive was generated by hypermail 2.1.6 : Wed Feb 25 2004 - 16:29:36 PST