Re: Codel and Wireless
Richard Bennett <[email protected]> Mon, 16 Dec 2013 17:10:26 -0800
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
It seems to me that indifference to applications and link layer conditions is not really a productive. On 12/16/13, 4:07 PM, Detlef Bosau wrote: > Am 17.12.2013 00:03, schrieb Markku Kojo: >> It is not only fq_codel that is likely to have problems over most >> wireless technologies but any proposed AQM today has hard time to >> work properly over wireless bottleneck links like LTE, 3G, GPRS, wifi, >> satellite, etc. > > Christmas time is coming :-) (I have "Holidays are coming" in mind, > however, I must not do any advertising here ;-)) > > Over time, I feared I were the only one to doubt AQM mechanisms over > wireless bottleneck links. > > >> For various reasons (some well justified some not so), these >> technologies tend to buffer significant amount of data below >> the IP layer (as Keith indicated), > The major reason is to utilize the highly volatile throughput. > > And it is of major importance not to empty necessary buffers here e.g. > as a consequence of congestion handling. > >> quite totally hidden from your >> favorite IP AQM/scheduling, > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > that's exactly what makes splitting appealing in this context: Necessary > buffers and their contents are hidden from TCP congestion control and > queue management! > >> i.e., without a very specific cross-layer >> implementation RED does not know the actual queue length, PIE is not >> able to correctly figure out the departure rate, and fq_codel is not >> able to calculate the correct sojourn time > > So, you understand my thoughts on this one? >> nor drop or schedule the packets from the actual heads of the queues. >> This is not to say that >> a properly working AQM/scheduling is not doable, but there is a big >> obstacle as long as we continue using such a strict layering model >> between the IP and link layer and enforce it in the implementations. > Thank you very much for posting this comment. >>> On 6 December 2013 11:16, Keith Winstein <[email protected]> wrote: >>> >>>> On Thu, Dec 5, 2013 at 6:22 PM, Andrew Mcgregor >>>> <[email protected]>wrote: >>>> >>>>> By the way, fq_codel is not a combination of SFQ and CoDel, but >>>>> something >>>>> else. The code deserves really close study to understand what is >>>>> really >>>>> going on there, because there is a very interesting contribution in >>>>> terms >>>>> of heuristically measuring whether flows are building queue in the >>>>> qdisc >>>>> or >>>>> not. Empirically, this works really well on user access links, >>>>> including >>>>> LTE, by my own direct observation having run it on my home >>>>> network's LTE >>>>> link for many months now. >>>> >>>> Andrew, I'd love to hear more about how you do this. Do you run >>>> fq_codel >>>> on the uplink or somehow also on the downlink? How do you prevent >>>> the LTE >>>> modem or baseband from buffering hundreds of kilobytes inside itself >>>> -- do >>>> you use an upstream traffic shaper (to prevent the LTE link from >>>> becoming >>>> the bottleneck) or something more sophisticated? >>>> >>>> Cheers, >>>> Keith >>>> >>> > -- Richard Bennett Visiting Fellow, American Enterprise Institute Center for Internet, Communications, and Technology Policy Editor, High Tech Forum