> what i really replied for is to ask, if i can forward your email to a > friend of mine who happens to be involved with telephony with his > company, i know zero about that, i do know he does use VoIP, so maybe he > finds your hack nifty > > | > | Jim > > hope you better luck next time in #gentoo-dev > > Daniel
Yes, please. roughly what I can spell out with patience is: I have borrowed some qos configs elsehwere, applied occam's razor, and been satisfied with controlling outbound traffic [using only vanilla modules and no user-space]. wrt to throttling inbound traffic: I have googled, inquired, and seen non-vanilla qos modules but have not found an authority with which to ask a few very specific questions about ingress. this means that inbound traffic is not throttled and i just take it easy on multithreaded transfers. goals: run 5-10% headroom inbound at all times for voip (and similar realtime udp streaming) on broadband, inbound and outbound. This reduces upstream packet-queuing which can postpone delivery of voip packets ideal solutions leading to the goal: 1) delay TCP packets, never drop. so far I haven't found an *tables vanilla kernel module which documents the delay facility of a packet class. the collective forum may have covered more ground than I have covered 2) monitor all conntrack'ed tcp windows, delay ACK, and shrink windows on large numbers of descriptors in realtime 3) files of implementation fit the regex /etc/*.d/qos (with package deps, but no artifacts) 4) lock down the reasons why IMQ non-vanilla module/patch is the only documented sane inbound qos filter on googled sources and why not to treat TUN vanilla module is not an identical facility... The answer to my unfinished questions may exist in places I haven't turned over, however, testing the variations of inbound and outbound qos configs is a slow process with alot of phone downtime and advanced router side-effects leading to reboots. Jim -- gentoo-dev@gentoo.org mailing list
