Re: AltQ + ng_iface

From: Daniel O'Connor (doconnor_at_gsoft.com.au)
Date: 07/29/05

  • Next message: Chuck Swiger: "Re: AltQ + ng_iface" 
    To: Chuck Swiger <cswiger@mac.com>
Date: Fri, 29 Jul 2005 11:14:59 +0930

    On Friday 29 July 2005 11:02, Chuck Swiger wrote:
    > Either the "established" or the "tcpflags !syn,ack" keywords in a rule
    > adding matching packets to a high-priority queue ought to do it...? Or
    > perhaps you meant something more specific than just "TCP packets with
    > TH_ACK" set? :-)

    Hmm, I guess you could make those skip the pipe..

    > Anyway, I'm not convinced that trying to classify packets within an
    > established TCP connection in order to place them on different queues is a
    > really good idea, since you're quite likely to reorder the packets by doing
    > so. I'd expect both latency and bandwidth of a TCP connection to suffer
    > very noticably if more than 10% or so of the packets arrive out of order...

    The theory is that by prioritising outgoing ACKs you don't cause downstream
    delays when your upstream is full. eg
    http://www.benzedrine.cx/ackpri.html

    > [ Hmm. I suppose that one could make an exception to the above
    > generalization if URG was set, but the TCP stack already makes an effort to
    > prioritize and deliver out-of-band urgent stuff as quickly as possible,
    > anyway, right? ]

    Maybe, but it doesn't appear to do a particularly good job for a lot of
    situations :) 

    -- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

    • application/pgp-signature attachment: stored
  • Next message: Chuck Swiger: "Re: AltQ + ng_iface"

    Relevant Pages

    • Re: AltQ + ng_iface
      ... but dummynet is a little inflexible and can't prioritise ACKs (for ... matching packets to a high-priority queue ought to do it...? ... meant something more specific than just "TCP packets with TH_ACK" set? ... TCP connection in order to place them on different queues is a really good ...
      (freebsd-net)
    • Re: Diagnose co-location networking problem
      ... 398 packets received by filter ... and records the elapsed time. ... TCP connection info: ... ttl stream length: 2500 bytes ttl stream length: 3750 bytes ...
      (freebsd-net)
    • Re: TCP ECN patch for review
      ... The gain with ECN was not in throughput but in the number of lost packets and retransmissions ... TCP connection traced: ... truncated data: 19440399 bytes truncated data: 7673 bytes ... data xmit time: 56.875 secs data xmit time: 56.875 secs ...
      (freebsd-net)
    • Re: if_rum dies on transmit...
      ... a TCP connection? ... as a rum device. ... it's related to timing of inbound/outbound packets. ... easiest way to avoid panics or re occurrences was to pull the dongle, ...
      (freebsd-current)
    • Re: if_rum dies on transmit...
      ... a TCP connection? ... According to Sam who had a quick look at the issue for me when I first noticed it, the rum driver is in pretty bad shape and should be expected to be flaky. ... I think it's related to timing of inbound/outbound packets. ... I would frequently trigger it when fetch ran as part of a port update, but it happened at other seemingly random times as well. ...
      (freebsd-current)