Re: AltQ + ng_iface
From: Julian Elischer (julian_at_elischer.org)
Date: 07/29/05
- Previous message: Chuck Swiger: "Re: AltQ + ng_iface"
- In reply to: Chuck Swiger: "Re: AltQ + ng_iface"
- Next in thread: Jeremie Le Hen: "Re: AltQ + ng_iface"
- Reply: Jeremie Le Hen: "Re: AltQ + ng_iface"
- Reply: Daniel O'Connor: "Re: AltQ + ng_iface"
- Reply: Daniel O'Connor: "Re: AltQ + ng_iface"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 28 Jul 2005 20:05:33 -0700 To: Chuck Swiger <cswiger@mac.com>
Chuck Swiger wrote:
> Daniel O'Connor wrote:
>
>> 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
>
>
> Ah. OK, it makes sense that delaying outgoing ACKs too much would
> slow things down. So you want to send dataless ACKs at a higher
> priority than generic big packets full of data, maybe via the "iplen"
> keyword with "established", look for packets smaller than ~100 bytes?
I do this to great effect..
consider:
two sites connected by links in which teh bottleneck is 200KB/sec (1 E1?)
when a lot of data is flowing from 1 to 2 then data from 2 to 1 is also
slowed
down because the acks have to go through the queues on ingress side of the
bottleneck router.
I add a dummynet entry on 1, limiting output to 190KB/sec, so that the queue
is in dummynet and not the intermediate router, and then allow small ack
packets
to bypass that queue. As a result the data from 2 to 1 also flows at
near capacity,
and with a much lower latency. SInce data flows tend to be large packets,
I sometimes actually prioitise ALL small packets allowing interactive
stuff to
bypass ftps etc. and sometimes I do it on both ends.
>
> My other thought on this is to wonder about window size and whether
> that was scaling properly up to a reasonable value, and whether both
> sides implement a sane network stack, or whether the other side was a
> windows box looking for quick responses and usage of SACK, rather than
> BSD (new-reno?) delayed ACKs...
>
>>> [ 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 :)
>
>
> I guess. :-) Getting 25% of the hoped-for max performance under a
> problematic case isn't so horrible, either, but I suspect other
> factors were involved, too.
>
> A tcpdump would've been informative....
>
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: Chuck Swiger: "Re: AltQ + ng_iface"
- In reply to: Chuck Swiger: "Re: AltQ + ng_iface"
- Next in thread: Jeremie Le Hen: "Re: AltQ + ng_iface"
- Reply: Jeremie Le Hen: "Re: AltQ + ng_iface"
- Reply: Daniel O'Connor: "Re: AltQ + ng_iface"
- Reply: Daniel O'Connor: "Re: AltQ + ng_iface"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
