From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by huchra.bufferbloat.net (Postfix) with ESMTP id CF1B221F0BA for ; Sat, 4 May 2013 12:24:04 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta04.emeryville.ca.mail.comcast.net with comcast id XvLz1l0031GXsucA4vQ4Wj; Sat, 04 May 2013 19:24:04 +0000 Received: from mail-ie0-x234.google.com ([IPv6:2607:f8b0:4001:c03::234]) by omta07.emeryville.ca.mail.comcast.net with comcast id XvQ31l00k58t75Q8UvQ4DJ; Sat, 04 May 2013 19:24:04 +0000 Received: by mail-ie0-f180.google.com with SMTP id ar20so2863303iec.39 for ; Sat, 04 May 2013 12:24:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IRdrJDPyjROdTQLzqS8a5nDeqbTN6+RuTxG/cbZScF0=; b=NXiJKm4HxOFGrCbf3qgvU9+O+qKygCB+y0TpLZbu2uNjkhEtKJ+/9kjOlxHzXl2owi lNvPeELXpMQuvdWfbtBFnggrLeoYHKJVYnjTl2iBMQJfEBV6CINZNX2b+YLtnME2K9Sw Qlm8Y1wd4TX6+sGBbyRhJK3LrdRkxRCx/nVcwEHT3wpx+bIWlE56MDW4kqhpYMarh46k 1mXe8N8QJUrENcOD5hUVAs8QuJWcYFim/emAxy2Xssx6qhXqeqsJMw6WavxTGza1F6Pj 8v2kOOYj4n12zYjm6yaX6wrg9jRJZ/TF8cmFMWmKXhQ4avBjgstaIVVtiANQ30qpVtH3 DcYg== MIME-Version: 1.0 X-Received: by 10.50.88.36 with SMTP id bd4mr881525igb.95.1367695443620; Sat, 04 May 2013 12:24:03 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Sat, 4 May 2013 12:24:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 May 2013 13:24:03 -0600 Message-ID: From: Kevin Gross To: Forums1000 Content-Type: multipart/alternative; boundary=089e013cc030144e5804dbe96971 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367695444; bh=IRdrJDPyjROdTQLzqS8a5nDeqbTN6+RuTxG/cbZScF0=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=MMG6j+GUDNKk2Dr6EHKLl1b/MjHtwlu2ZyHOgF+Rx1BwRPEnwX9iwrSQL/c1Ng73+ fHSAZLW4Ley9A0MP+jEocbdVSUZ5cIZPx2vXSq4Ni5y49zcsV+vYC3CBXMpLBCfkPk K8kPJiDQ+vL5y7troPLCRDzumXlTlWxqDAcluMWXmhfNLPZMjR81JQpFy7dmc9i2nU 7QXEUzivqp1MDjnPZfbcd0pULgpsfWR/a+otGsowG5Blitmj75ebvPRsHdLSKHxpAb FFA2APefQ/IrmKSqRMowdHtDUa+7wdh2wwhPIc2BtnrZJHmLXpuyqyxPratnR/xtWn IVLn1RKfMd+dQ== Cc: bloat Subject: Re: [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: Sat, 04 May 2013 19:24:04 -0000 --089e013cc030144e5804dbe96971 Content-Type: text/plain; charset=ISO-8859-1 Not quite UDP, but RTP congestion avoidance is being worked on in the IETF. Please join us - http://datatracker.ietf.org/wg/rmcat/charter/ Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Thu, May 2, 2013 at 5:44 AM, Forums1000 wrote: > 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 > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --089e013cc030144e5804dbe96971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Not quite UDP, but RTP congestion=A0avoidance=A0is=A0being= =A0worked on in the IETF. Please join us -=A0http://datatracker.ietf.org/wg/rmcat/charter/

On Thu, May 2, 2013 at 5:44 AM, Forums10= 00 <forums1000@gmail.com> wrote:
I hope I can get a bit more information on what compr= ises 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=20 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=20 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=20 taking into account that the most aggressive flow (the flow that=20 contributes the most to filling a buffer), is the flow that will get the most packets dropped. This to prevent the aggressive flow from=20 impacting flows that behave better.

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

Any good resources are more than welcome:-)!
Thanks,
Jeroen

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat


--089e013cc030144e5804dbe96971--