From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) (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 E5FD221F18F for ; Thu, 2 May 2013 04:45:13 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id b10so228576eae.2 for ; Thu, 02 May 2013 04:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=X/0bQ4JjRZTecr3tugKJD6P0bhBm6xnyuju2p93l/I4=; b=OcM8HECs2XCO7/H+GfQx0h/K/bfIjUDPm5ey/2xlfPXvKEhecItxCkcDpbGEIBQLXd pE75vSt4WjR+LWWQsW++dygRJ3VHk4bZICmqrD/jb7xGu4grLaT6KffLBL9PBMZGZJug BJqZL4O0UMDBvc5ly9Kz3vbFR5sQ2nlfJQ3ziblcn0DJu7VSk4LzQ0EyzEmUQC2drJyk D5tWq5Ybzfdz8ZYy3KWcMhTrGWV3iK7r4CKekEGAWOgXxvCsucb+esbG6wqBFrRbXC3N XSDjJSLzXy5hLTFyVn67YJcIUrsk8AVKSC3obEZ9pbvAGPnFqcbnTYZVhHK2aIR4Wunk 7S7A== X-Received: by 10.15.23.69 with SMTP id g45mr18744653eeu.25.1367495111897; Thu, 02 May 2013 04:45:11 -0700 (PDT) MIME-Version: 1.0 Sender: jeroen.balduyck@gmail.com Received: by 10.14.145.79 with HTTP; Thu, 2 May 2013 04:44:41 -0700 (PDT) From: Forums1000 Date: Thu, 2 May 2013 13:44:41 +0200 X-Google-Sender-Auth: Y1YK2v0_hDzNo_F71q05DAOrJYs Message-ID: To: bloat Content-Type: multipart/alternative; boundary=089e016351b060983a04dbbac418 Subject: [Bloat] The bigger picture: what components are used together to fight bloat 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: Thu, 02 May 2013 11:45:14 -0000 --089e016351b060983a04dbbac418 Content-Type: text/plain; charset=ISO-8859-1 I hope I can get a bit more information on what comprises the total solution. But knitting it together proves a bit hard (for me at least). Without this, it is hard to follow the discussions on the list. Has anyone made a summary of how all of this works together? So: 1. In order to move the bottleneck to a device under our administrative control, we need to shape traffic (we need to become the bottleneck). 2. Next, we have the AQM-algorithms that manage the (or a) queue. 3. And then there are still issues with multiple flows and with UDP? >From what I understand, we need to shape traffic, and then drop packets taking into account that the most aggressive flow (the flow that contributes the most to filling a buffer), is the flow that will get the most packets dropped. This to prevent the aggressive flow from impacting flows that behave better. Now for UDP, is the problem here that we cannot identify flows, and hence, only have one queue for UDP whereas for TCP we can have multiple? Any good resources are more than welcome:-)! Thanks, Jeroen --089e016351b060983a04dbbac418 Content-Type: text/html; charset=ISO-8859-1
I hope I can get a bit more information on what comprises the total solution. But knitting it together proves a bit hard (for me at least). Without this, it is hard to follow the discussions on the list. Has anyone made a summary of how all of this works together?

So:

1. In order to move the bottleneck to a device under our administrative control, we need to shape traffic (we need to become the bottleneck).
2. Next, we have the AQM-algorithms that manage the (or a) queue.
3. And then there are still issues with multiple flows and with UDP?

From what I understand, we need to shape traffic, and then drop packets taking into account that the most aggressive flow (the flow that contributes the most to filling a buffer), is the flow that will get the most packets dropped. This to prevent the aggressive flow from impacting flows that behave better.

Now for UDP, is the problem here that we cannot identify flows, and hence, only have one queue for UDP whereas for TCP we can have multiple?

Any good resources are more than welcome:-)!

Thanks,
Jeroen
--089e016351b060983a04dbbac418--