From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm17-vm5.access.bullet.mail.gq1.yahoo.com (nm17-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C6D6421F2B8 for ; Mon, 12 May 2014 13:26:13 -0700 (PDT) Received: from [216.39.60.173] by nm17.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 May 2014 20:26:13 -0000 Received: from [67.195.22.118] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 May 2014 20:26:12 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 12 May 2014 20:26:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1399926372; bh=u1O52VyZK0nsGM5AWdKIak5RJ03h2Lstjro/EssbGSM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=DlmukPwOQm7fF98++rxq/L9xe47Nx2AuE1aGbNvbtykL9nJHCykWyqbr2a/k+CWo6TCbYePr095JJ1Cc2lyRl08MkjJ+lvOlq8VLBZbSb+VbXbh8N6zDExbTyTLiJl6TEJ9E1gyfRwjtQ8pyEVUZf/f4J+xtrNU1LMrdHnmhQyQ= X-Yahoo-Newman-Id: 897479.94563.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0mowVrkVM1lAoqXhgw4ivw4uJcUqNHMy6J8C3KIXf3Auyjf VuaozQZu_JO_JsEpdwgnqlRejM1k.enySfRZThXot16oXAjAUUNTV86wJHic U58qjm_Go4Xwo6SxuOlR9fU44TP8y9HQ3Lw3kDJODE.1crg6BBlYzOl2ne6n iteX26swsPzbuIcm6BjDX3rZzu9PdFnfWBw0n2m_6fsr6_q5XZ5XOPWV1vpS v7dY.xwBIKX2Bsq2pZjlpcPyoycJi27po6GoRAsWrn5U0TdRqTCrFzBOzJ7M XU0AVPyFURziV2m_f9TikCOXKyTI.8P4kwphpgnTl288koyToWcesNpFhNsZ XvK1WsyUaqBUHOwNRvAhupD7PVx3jQsBe99Z2uch1DIbyue0H.YQSNiW4bEN Yv0oQoxZW3Qfd6VDbuPCfuOaghcEfLsOsUr_Q.hKuDF906ncQQAfoYTtPPww Ue_9CryWP.lSlDZNEEXtY2af0H2v0rBCy30fZsP_RrL4pGdpq64.X3xvisA3 Fhg_RHViKEzD180B2grGHxFdngQvmSr2Foa_eLr6OrBQkQLooKb910My_F4W GhDI- X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- X-Rocket-Received: from [10.104.56.205] (davec-b@75.98.19.132 with plain [67.195.22.104]) by smtp113.sbc.mail.gq1.yahoo.com with SMTP; 12 May 2014 13:26:12 -0700 PDT Message-ID: <53712E57.10906@rogers.com> Date: Mon, 12 May 2014 16:25:59 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] How is bufferbloat prevented/fixed for UDP? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: davecb@spamcop.net List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 20:26:14 -0000 Forums1000 asked > Curiously, there is little information to be found regarding bufferbloat > and UDP. > > I did find hints briefly alluding to some problems: > > 1)With UDP, you cannot uniquely identify a flow? This prevents an > AQM-algorithm to drop packets for an (several) offending UDP flow(s). > > 2) Unlike TCP, UDP does not back down when encountering packet loss > > So how does UDP fit in concerning efforts to combat bufferbloat? Having one > queue to mange all UDP 'flows' does not seem like a good approach. > > Thanks for shining a light on this:-) > > Jeroen Bufferbloat, or more correctly the lack of congestion control in UDP, is a problem for the designers of individual UDP-using programs. The behaviour of the program during congestion is a problem for everyone else (;-)) To oversimplify, - If the UDP programs is small-data punt and hope, no-one needs care. Very few such programs exist. - if the UDP programs is a stop-and-wait one like TFTP, it will be a self-limiting load on the net, and can be throttled by drops. This is similar to... -- if the program is self-limiting, such as VOIP or video, we really should be prepared to signal congestion to it using AQM or drops, but I don't know if anyone is doing such using UDP. Someone else on the list will know. - if the program uses resends, it will survive congestion control by drops, and if the program is very heavily used, we may need to provide congestion control for it, or we'll get "bloated". If everyone in the world suddenly switched to UDP for web pages, we'd need to identify such TCP-like streams and throttle them via packet drops, to avoid congestive collapse. - if the UDP program is large-data punt-and-hope, it would be both randomly unreliable and harmful to the net. In that case, I think we might need to hunt down the author and suggest something, quick before he goes out of business for bringing down the net. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain