On Aug 28, 2014, at 9:20 AM, Jerry Jongerius <jer...@duckware.com> wrote:
> It add accountability. Everyone in the path right now denies that they could > possibly be the one dropping the packet. > > If I want (or need!) to address the problem, I can’t now. I would have to > make a change and just hope that it fixed the problem. > > With accountability, I can address the problem. I then have a choice. If > the problem is the ISP, I can switch ISP’s. If the problem is the mid-level > peer or the hosting provider, I can test out new hosting providers. May I ask what may be a dumb question? All communications has some probability of error. That’s the reason we have CRCs on link layer frames; to detect and discard errored packets. The probability of such an error varies by media type; it’s relatively uncommon (O(10^-11)) on fiber, a little more common (perhaps O(10^-9)) on wired Ethernet, likely on Wifi (O(1p^-7 or so), which is why Wifi incorporates local retransmission), and very likely (O(10^-4)) on satellite links, which is why they use forward error correction. Errors are not usually single bit errors. They are far more commonly block errors, especially if trellis coding is in use, as once there is an error the entire link goes screwy until it works out where the data is going. Such block errors might consume entire messages, or sets of messages, including not only the messages but the gaps between them. When a message is lost due to an error, how do you determine whose fault it is? > - Jerry > > > > From: Rich Brown [mailto:richb.hano...@gmail.com] > Sent: Thursday, August 28, 2014 10:39 AM > To: Jerry Jongerius > Cc: Greg White; Sebastian Moeller; bloat@lists.bufferbloat.net > Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? > > Hi Jerry, > > AQM is a great solution for bufferbloat. End of story. But if you want to > track down which device in the network intentionally dropped a packet (when > many devices in the network path will be running AQM), how are you going to > do that? Or how do youpropose to do that? > > Yes, but... I want to understand why you are looking to know which device > dropped the packet. What would you do with the information? > > The great beauty of fq_codel is that it discards packets that have dwelt too > long in a queue by actually *measuring* how long they've been in the queue. > > If the drops happen in your local gateway/home router, then it's interesting > to you as the "operator" of that device. If the drops happen elsewhere > (perhaps some enlightened ISP has installed fq_codel, PIE, or some other > zoomy queue discipline) then they're doing the right thing as well - they're > managing their traffic as well as they can. But once the data leaves your > gateway router, you can't make any further predictions. > > The SQM/AQM efforts of CeroWrt/fq_codel are designed to give near optimal > performance of the *local* gateway, to make it adapt to the remainder of the > (black box) network. It might make sense to instrument the CeroWrt/OpenWrt > code to track the number of fq_codel drops to come up with a sense of what's > 'normal'. And if you need to know exactly what's happening, then > tcpdump/wireshark are your friends. > > Maybe I'm missing the point of your note, but I'm not sure there's anything > you can do beyond your gateway. In the broader network, operators are > continually watching their traffic and drop rates, and > adjusting/reconfiguring their networks to adapt. But in general, it's > impossible for you to have any sway/influence on their operations, so I'm not > sure what you would do if you could know that the third router in traceroute > was dropping... > > Best regards, > > Rich > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
