Re: Fast TCP

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 06/22/03

  • Next message: Robin T Cox: "Re: Registry-blocking writing to"
    Date: Sun, 22 Jun 2003 15:44:49 GMT
    
    

    toro <toro@valhalla.net> writes:
    > I read about the new TCP and the fact that it allows enormous data
    > transfer rates by changing the error handling procedure. Since I am
    > still learning the TCP/IP protocol, I was wondering whether this
    > speed would help the stability of the infastructure and in which way

    basically the bits can't go faster than the wire. the issues in tcp is
    chaotic network with seemingly random hops between any two end points
    are:

    1) protocol setup chatter
    2) pacing

    lots of tcp apps have used a windowing algorithm as an indirect
    mechanism to control pacing. windowing basically is a facility for
    managing end-point buffer resources, it only indirectly controls
    pacing issues like packet transmit rate, packet arrival rate,
    inter-packet transmit interval, etc.

    one of the most common implemented algorithms is slow-start ... which
    I believe was presented at '88 august ietf meeting, the same month
    that a acm sigcomm proceedings had paper showing that slow-start is
    non-stable in any sort of real-world environment.

    one of the past discussions was that transmitting a slew of
    back-to-back packets can cause overrun at intermediate router boxes.
    In theory, (slow-start) windowing is to try and mitigate things like
    bursts of packet transmissions from a source. The problem found in the
    '88 sigcomm paper was that in real world situations, the return ACK
    packets can bunch up, with a batch arriving at the source all at once.
    In a windowing paradigm, receiving a batch of ACKs means that all the
    associated buffers are freed up for transmission in one burst, leading
    to potentially several back-to-back packets being transmitted very
    quickly. This can lead to congestion, lost packets, back-off and
    restarting the slow-start mechanism, gradually increasing number of
    outstanding packets until the next burst of batched ACKs appears and
    the cycle starts again. All of these protocol stuttering issues
    contribute to the effective delivered packet rate being less than the
    wire-speed.

    Rate-based pacing would explicitly measure approximate elapsed
    round-trip delay and then do something like methodically adjust the
    inter-packet transmission delay. This directly controls factors that
    can account for congestion and intermediate node overruns and is also
    insensitive to network operation peculiarities like ACK batching.

    One of the comments regarding the use of windowing algorithm in the
    '80s instead of direct timer control was that possibly a large number
    of the 80s-era platforms lacked the timer facilities to implement
    things like inter-packet transmit delay.

    there was a much longer discussion on the subject in
    comp.protocols.tcp-ip

    misc. recent related threads:
    http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
    http://www.garlic.com/~lynn/2003g.html#45 Rewrite TCP/IP
    http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
    http://www.garlic.com/~lynn/2003h.html#7 Why did TCP become popular ?
    http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
    http://www.garlic.com/~lynn/2003j.html#39 tunneling TCP/IP over UDP for high-latency links?
    http://www.garlic.com/~lynn/2003j.html#40 tunneling TCP/IP over UDP for high-latency links?

    -- 
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
    Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
    

  • Next message: Robin T Cox: "Re: Registry-blocking writing to"

    Relevant Pages

    • Re: UPD better than TCP in streaming video/audio ?
      ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
      (microsoft.public.win32.programmer.networks)
    • Re: Simulating smaller MTU? ie sending small packets.
      ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
      (comp.lang.perl.misc)
    • Re: NTP and Firewall help needed.
      ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
      (comp.os.linux.setup)
    • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
      ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
      (freebsd-performance)
    • Re: UDP vs TCP
      ... TCP for instance will break up a large packet into smaller ... into the packets and then the receiving app would have to read ... Network Layer -> ethernet ... DOMAIN over port 53 ...
      (microsoft.public.vb.enterprise)