Re: v6 Avian Carriers?
Original Message - From: Steven Bellovin s...@cs.columbia.edu Which? African or European Swallows? (Watches Chad fly over the cliff edge) ;-) So the RFC needed more text in it's Security Considerations section, too... People just don't put enough *thought* into their April 1 RFCs anymore... Cheers, -- jra
RE: State of QoS peering in Nanog
-Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Saturday, April 02, 2011 5:56 PM In an IP network, the bandwidth constraints are almost always across an administrative boundary. This means in the majority of the case across transit circuits, not peering. 80-90% of the packet loss in the network happens at the end user access port, inbound or outbound. Another 5-10% occurs where regional or non-transit free providers buy transit. Lastly, 3-5% occurs where there are geographic or geopolitical issues (oceans to cross, country boarders with restrictive governments to cross). Hi Leo, I think you bring up some interesting points here, and my experience and observations largely lend credence to what you are saying. I'd like to know however, just for my own personal knowledge, are the numbers you are using above based on some broad analysis or study of multiple providers, or are you deriving these numbers likewise you're your own personal observations? Thanks, Stefan Fouant
RE: State of QoS peering in Nanog
-Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Saturday, April 02, 2011 10:24 PM But it also only affects priority queue traffic. I realize I'm making a value judgment, but many customers under DDoS would find things vastly improved if their video conferencing went down, but everything else continued to work (if slowly), compared to today when everything goes down. I'd like to observe that discussion when the Netflix guys come calling on the support line - Hey Netflix, yeah you're under attack and your subscribers can't watch videos at the moment, but the good news is that all other apps running on our network are currently unaffected. ; In closing, I want to push folks back to the buffer bloat issue though. More than once I've been asked to configure QoS on the network to support VoIP, Video Conferencing or the like. These things were deployed and failed to work properly. I went into the network and _reduced_ the buffer sizes, and _increased_ packet drops. Magically these applications worked fine, with no QoS. Video conferencing can tolerate a 1% packet drop, but can't tolerate a 4 second buffer delay. Many people today who want QoS are actually suffering from buffer bloat. :( Concur 100%. In my experience, I've gotten much better performance w/ VoIP/Video Conferencing and other delay-intolerant applications when setting buffer sizes to a temporal value rather than based on a _fixed_ number of packets. Stefan Fouant
Submission
I thank you for all the ideas that we get to exploit from this site...
Re: IPv4 Address Exhaustion Effects on the Earth
On 04/01/2011 11:44 AM, George Bonser wrote: From: Joao C. Mendes Ogawa Sent: Thursday, March 31, 2011 6:14 PM Subject: Fwd: IPv4 Address Exhaustion Effects on the Earth FYI --Jonny Ogawa - Forwarded message from Stephen H. Inden - Dang, I was hoping to see an RFC on Bufferbloat in Avian Carriers and how tail-drop is a messy solution that is to be avoided. Sigh... A major opportunity missed. Unfortunately the bufferbloat problem isn't a laughing matter, though I do wish I had thought of this idea in time for my talk. I will include this joke as some levity about the mess we're in as I repeat the talk going forward, and would tie in very nicely with one of the amusing reasons that RED in a different light has never been published. I really hate giving such bad news without some levity as it can be a real downer both for me and the audience. For those of you who missed my IETF talk, you can find the latest version (tweaked since IETF) at: http://mirrors.bufferbloat.net/Talks/PragueIETF/ I suspect audio is some place on the net as well; I presented at the transport area meeting. The questions after my talk are also very worth listening to. Time was precious in that venue, so I did feel rushed and hope to get a better opportunity in a month or two for that. It's a shorter version of my first talk given at Murray Hill http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ which does have additional information impossible to fit in that short a time slot. - Jim
Re: IPv4 Address Exhaustion Effects on the Earth
The audio I found at http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch4-wed-am.mp3 Christian On 3 Apr 2011, at 20:53, Jim Gettys wrote: On 04/01/2011 11:44 AM, George Bonser wrote: From: Joao C. Mendes Ogawa Sent: Thursday, March 31, 2011 6:14 PM Subject: Fwd: IPv4 Address Exhaustion Effects on the Earth FYI --Jonny Ogawa - Forwarded message from Stephen H. Inden - Dang, I was hoping to see an RFC on Bufferbloat in Avian Carriers and how tail-drop is a messy solution that is to be avoided. Sigh... A major opportunity missed. Unfortunately the bufferbloat problem isn't a laughing matter, though I do wish I had thought of this idea in time for my talk. I will include this joke as some levity about the mess we're in as I repeat the talk going forward, and would tie in very nicely with one of the amusing reasons that RED in a different light has never been published. I really hate giving such bad news without some levity as it can be a real downer both for me and the audience. For those of you who missed my IETF talk, you can find the latest version (tweaked since IETF) at: http://mirrors.bufferbloat.net/Talks/PragueIETF/ I suspect audio is some place on the net as well; I presented at the transport area meeting. The questions after my talk are also very worth listening to. Time was precious in that venue, so I did feel rushed and hope to get a better opportunity in a month or two for that. It's a shorter version of my first talk given at Murray Hill http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ which does have additional information impossible to fit in that short a time slot. - Jim
RE: IPv4 Address Exhaustion Effects on the Earth
Sigh... A major opportunity missed. Unfortunately the bufferbloat problem isn't a laughing matter, though I do wish I had thought of this idea in time for my talk. I will include this joke as some levity about the mess we're in as I repeat the talk going forward, and would tie in very nicely with one of the amusing reasons that RED in a different light has never been published. I really hate giving such bad news without some levity as it can be a real downer both for me and the audience. Speaking of Van's paper, has that ever been located/revived? Is it available beyond that one earlier draft that is available on the Internet? George
