From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 34A02201A58 for ; Mon, 30 May 2011 08:13:30 -0700 (PDT) Received: by wyb32 with SMTP id 32so3906377wyb.16 for ; Mon, 30 May 2011 08:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lT9rgu+7ws/sKjmskMe74Tl5ErItQa6cYel/LspkOT8=; b=oXdaLqNqiO5C0GRxN3mdSNKegpTLVuIZwFMuX2TLoWPENBj7qGLkcCWGjK6+ROOzDn cE16rYp7Whh3QbNFEaRZHWaEqdJ+Y+KyIz708T/flbEWm15iKAYAKE4uZmILb0uCCsnF eBYYT+l6kXvEnW0oxlwDFF8efx9yOT+Rp5qfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ncXWFfu9Xe65+QKKWnZ5KUsDGhX0ywefKsmNe6nGML/+pO1sRjOxkC+ldnpXA5/Lxv z1YghWZcLArK2zLtuvOnmkbH6gPHrDJAeCHaLygMEDmLP6VCM2LbHjYL094t4K1VIaIL P5zdHJGnFHPiKB79qq8rbap4YCln/EgGL3Wmo= MIME-Version: 1.0 Received: by 10.216.69.74 with SMTP id m52mr5525961wed.33.1306769384405; Mon, 30 May 2011 08:29:44 -0700 (PDT) Received: by 10.216.185.13 with HTTP; Mon, 30 May 2011 08:29:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 May 2011 08:29:44 -0700 Message-ID: From: "George B." To: Dave Taht Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] philosophical question X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 15:13:30 -0000 On Mon, May 30, 2011 at 5:25 AM, Dave Taht wrote: > > > On Sun, May 29, 2011 at 10:24 PM, George B. wrote: >> >> Ok, say I have a network with no over subscription in my net. > > I'd love to see one of those. Can I get on it? Well, we currently have the potential for some microburst oversub inside the data center but not too much of it. I can take a 48-port GigE switch and have 40G of uplink but the switches aren't fully populated yet. Bottlenecks are currently where we might have 25 front end servers talking on GigE to a backend server with 20G. So some potential for internal microburst oversub but that's beyond the scope of this discussion. >> >> I have >> 10G to the internet but am only using about 2G of that. =A0This is the >> server side of a network talking to millions of clients. =A0The clients >> in this case are on "lossy" wireless networks where packet loss is not >> an indication of congestion so much as it is an indication that the >> client moved 15 feet behind a pole and had poor network connectivity >> for a few minutes. >> > Or is using multicast. Multicast is a fact of life with which one is going to have to learn to live. Better to somehow get the gear handling it in a better fashion, in my opinion. >> The idea being that in today's internet, packet loss is not a good >> indication of congestion. =A0Often it just means that the radio signal >> has been briefly interrupted. =A0What I need is something that can tell >> the difference between real congestion and radio loss. =A0ECN seems to >> be the way forward in that respect. >> > Yes. When it works. Which is rarely. I have enabled ECN (been following various bufferbloat discussions for a while) on a couple of machines and also my own machine (my own in order to see where it might cause any problems browsing) without any problems so far. "Back in the day" when ECN first came out on Linux, it was enabled by default and caused all sorts of issues with sites that simply drop packets with either/any of the ECN bits set. So far there haven't been any issues that I have run into with ECN set on my Windows laptop. Once I am convinced that setting that those bits isn't going to cause problems, I will roll that out in a more general fashion. But if networks upstream from us clear those bits anyway, I'm not convinced what difference it will make. There is also one fairly small subnet in the overall network where I have enabled "random-detect ecn" with a policy map on a potentially oversubscribed link. But that is the only router in the network that even supports ECN. I have sent an inquiry to the manufacturer of the rest of the gear about supporting ECN with their WRED implementation but haven't heard anything from them on the subject. >> But assuming my network, as a server of content is not over >> subscribed, what would you suggest as the best qdisc for such a >> traffic profile? In other words, I am looking at this from the server >> aspect rather than from the client aspect. >> > > Ah, ok. This was discussed in this loooong thread: > > https://lists.bufferbloat.net/pipermail/bloat/2011-March/000272.html > > Some form of fair queuing distributes the load to the ultimate end nodes > better. Ok, as we are using Linux (mostly) for the servers talking to the clients, it shouldn't be much of an issue to put into place. Thanks to the pointer to the thread and I will watch as things develop and see how things go. > As for which packet scheduler to choose for that? Don't know, I'm just > trying to get to where we can actually test stuff on the edge gateways at > this point. Yeah, what I am most interested in are things like smart phones/laptops/tablets and not necessarily on WiFi but also on 3/4g networks. Those things are pulling a lot of traffic these days and the network can be lossy at times. From my own analysis of traffic captures, it is fairly easy to see when a device that is "on the move" changes cell towers. You get a burst of resends and often some out of order packets and then things settle down for a while. This isn't so big of a deal if you have only a few mobile clients but sites that cater to mobile content might have millions of such clients connected at any given time with many of them in a state where they have marginal connectivity or are in the process of moving between towers. So the TCP notion that "packet loss =3D=3D congestion" doesn't apply in those networks. With those, packet loss is just packet loss and shouldn't be treated as congestion. This is why I think it is so important to get ECN working across the Internet. But even with ECN capable end points, if the routers in the middle are not capable of using ECN to signal congestion and simply drop packets, there is always a question of why the packet was lost. We need to hammer on our vendors a bit and get them properly supporting ECN to signal congestion on ECN aware flows. > Dave T=E4ht Thanks, all! g