After some sleep and a good breakfast, I seem to be able to think more clearly.
I have come upon these conclusions: 1. Qos is all about managing upload packets ( and download packets indirectly by managing upload packets). 2. The ceiling kbit actually refers to your upload speed. It is important to keep your ceiling kbit lower than the modem upload speed, otherwise a queue gets built in the modem (most likely a FIFO queue). 3. Therefore any packets that needs to be uploaded when we hit the ceiling kbit needs to be delayed in our linux queue and prioritized according to rules that we make with tc. 4. TCP needs the ACK packets to know if packets sent have been received. It will only send more data packets if it gets this ACK back. Therefore, a delay in the return ACK packets (if you are downloading, your machine should upload ACK packets back) means TCP slows down and your download does too. 5. VOIP uses udp packets, which are fire and forget packets (no ACK packets to worry about). Therefore, to optimize VOIP, we need to put its udp packets in priority 0 with a fast FIFO queue there. 6. We probably want to put ACK in the next priority 1 and then the rest of the packets in lower priorities. 7. Qos doesn't impact incoming packets except to the extent that it influences the upload ACK packets because as soon as a packet hits your interface, its already there. If the packets are destined to the LAN, then you might setup a Qos between machines too. If these assumptions are correct, then what I see on class 1:102 is actually upload ACK packets since I see activity in that class when I do a download. Of course, I could be way out on left field here. Anybody care to comment? Thanks. I will continue my research. On Sun, 2005-04-10 at 10:05, Andrew Kohlsmith wrote: > On April 10, 2005 04:47 am, cmisip wrote: > > I got this from the voip wiki but the original script didn't seem to > > work right so I fiddled with it a little bit. I am no expert so maybe > > someone can look at it for errors. This is for my cable connection. So > > far asterisk seems to use 1:10 while all other traffic uses 1:102. How > > does one packet shape RTP? > > That looks like my rc.tc script. The most up to dateA version is at > http://www.mixdown.ca/~andrew/dump/rc.tc. Please note that it only tries to > make things happy for IAX2. It should be fairly easy to add RTP packet > detection and to throw them into the same queue. > > -A. > _______________________________________________ > Asterisk-Users mailing list > [email protected] > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
