From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by huchra.bufferbloat.net (Postfix) with ESMTP id 8692321F1A4; Tue, 7 May 2013 09:30:23 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r47GUMWv016418; Tue, 7 May 2013 10:30:22 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 07 May 2013 10:30:22 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0123.003; Tue, 7 May 2013 10:30:22 -0600 From: Greg White To: Michael Richardson , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , "bloat@lists.bufferbloat.net" Thread-Topic: [Bloat] [Cerowrt-devel] Latest codel, fq_codel, and pie sim study from cablelabs now available Thread-Index: AQHOS0AreN0zjj/CIkmF64FNSMd0+Q== Date: Tue, 7 May 2013 16:30:21 +0000 Message-ID: In-Reply-To: <19404.1367933465@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.4.10.57] Content-Type: text/plain; charset="us-ascii" Content-ID: <55851586FC292040AFC017A7B11FAF9F@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Codel] [Bloat] [Cerowrt-devel] Latest codel, fq_codel, and pie sim study from cablelabs now available X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 16:30:23 -0000 This presumes that UDP is the only traffic that is latency sensitive (we also consider web traffic to be latency sensitive), and that TCP carries the bulk data that causes problems for latency sensitive traffic (AFAIK BitTorrent uTP is layered on top of UDP). I'm not sure that a TCP/UDP distinction ends up helping in the end. -Greg On 5/7/13 7:31 AM, "Michael Richardson" wrote: > >>>>>> "Simon" =3D=3D Simon Barber writes: > Simon> Or one could use more queues in SFQ, so that the chance of 2 > Simon> streams sharing > Simon> a queue is small. Even perhaps use a different strategy than > Simon> hashing to > Simon> distribute traffic to queues, although whatever strategy is > Simon> used needs to be > Simon> resistant to DoS attacks. Or one could classify the VoIP >traffic and > Simon> prioritise that. Another possibility is a heuristic approach > Simon> - don't mix long > Simon> lived bulk data streams in the same bucket as others. > >1) try to give each IPv6 non-zero flow label stream to it's own bucket. > (use a closed hashing strategy) > Yes, this leverages an IPv6 feature which should promote v6... > >2) otherwise, hash TCP and UDP streams into seperate pools. On simple > networks with no gaming, this results in VoIP RTP flows and DNS > always getting their own stream. > On networks with agressive UDP flows which do not react, one needs > another method to seperate the flows and penalize them individually. > if NAT is involved, then conn-tracking can basically give every flow > it's own queue, because they are already uniquely identified. > > I think that the number of queues for TCP streams can be smaller than > for UDP streams, as the TCP streams are more likely to respond to > congestion signals. > >--=20 >] Never tell me the odds! | ipv6 mesh >networks [=20 >] Michael Richardson, Sandelman Software Works | network >architect [=20 >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [=20 >=09 > >_______________________________________________ >Bloat mailing list >Bloat@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/bloat