From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C07E921F225 for ; Mon, 2 Mar 2015 11:07:02 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id hy10so1451001vcb.4 for ; Mon, 02 Mar 2015 11:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iJJnZrsOT5T99yQE2sNrgJ4kPmSSKSMRJXcPb2SDQrk=; b=VSmkMh5M+/Qwn7pEs6bevtKi6b91Aptxej4fZdkPHB8uCiH+VwfpiCqG+XpBCcN/5C XrsM2zuocij4wY5YMtieG205jt5R4ACAQzSHSAX3ne7Sdo/rzfIFg4Xsp/1D+3/9WNgI ZVEKDxZMIqDTK+nkBbzY9UvPMcgCmipIYEY/OWEPm8nw5RY+i5Sh/ALp2UUhvR9rXCxh LTU5D/Won5lpiKv369JrRDPXf7BomUTUlL3Ee51aSh7xRho8eF3+RcuRvAPPVW7rfs8E mBrbWoEYD2EunTg37S/H7xuSTPGqdQNckFXdNmPNsbvz5blaL24tQrrkOQcd8T1jo26k 380A== MIME-Version: 1.0 X-Received: by 10.52.12.138 with SMTP id y10mr25861353vdb.35.1425323221434; Mon, 02 Mar 2015 11:07:01 -0800 (PST) Received: by 10.52.24.79 with HTTP; Mon, 2 Mar 2015 11:07:01 -0800 (PST) Received: by 10.52.24.79 with HTTP; Mon, 2 Mar 2015 11:07:01 -0800 (PST) In-Reply-To: References: <5EDCCC18D27F4F039FA971B3C834A466@srichardlxp2> <20150226151457.75fc898b@urahara> Date: Mon, 2 Mar 2015 21:07:01 +0200 Message-ID: From: Jonathan Morton To: divya singla Content-Type: multipart/alternative; boundary=485b397dd6374dc711051052ec8d Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] About Packet Drop in Codel 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: Mon, 02 Mar 2015 19:07:31 -0000 --485b397dd6374dc711051052ec8d Content-Type: text/plain; charset=UTF-8 With UDP, you're at the mercy of the application using it. With TCP, you're merely at the mercy of the operating system. AQM acts on UDP packets in the same way as TCP packets - in fact it can't tell them apart. So any application which detects and responds to UDP packet loss in the same way as TCP does, will back off just the same. In practice, UDP is used for several different types of application: - simple request response, such as DNS and NTP, where eliminating TCP's connection setup overhead is important. In any case, TCP's congestion control doesn't get a chance to do any good on such s short-lived connection. Packet loss in this situation is tolerated by retry, with exponential backoff as an alternative congestion control measure. - latency sensitive and often isochronous (inelastic) flows like VoIP. Packet loss may lead to a loss of quality, but there is little the application can do to reduce its loss except dropping the call completely. - as a way to implement delay sensitive and pacific congestion control algorithms, as in uTP. A flow isolation system, such as that in fq_codel, will often leave UDP flows alone completely, because they tend not to be the ones using the bulk of the bandwidth. Conversely, if a single UDP flow was responsible for the congestion, it would let the other traffic bypass it. This is why fq_codel is better than just plain codel, if you can get it. - Jonathan Morton --485b397dd6374dc711051052ec8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

With UDP, you're at the mercy of the application using i= t. With TCP, you're merely at the mercy of the operating system.

AQM acts on UDP packets in the same way as TCP packets - in = fact it can't tell them apart. So any application which detects and res= ponds to UDP packet loss in the same way as TCP does, will back off just th= e same.

In practice, UDP is used for several different types of appl= ication:

- simple request response, such as DNS and NTP, where elimin= ating TCP's connection setup overhead is important. In any case, TCP= 9;s congestion control doesn't get a chance to do any good on such s sh= ort-lived connection. Packet loss in this situation is tolerated by retry, = with exponential backoff as an alternative congestion control measure.

- latency sensitive and often isochronous (inelastic) flows = like VoIP. Packet loss may lead to a loss of quality, but there is little t= he application can do to reduce its loss except dropping the call completel= y.

- as a way to implement delay sensitive and pacific congesti= on control algorithms, as in uTP.

A flow isolation system, such as that in fq_codel, will ofte= n leave UDP flows alone completely, because they tend not to be the ones us= ing the bulk of the bandwidth. Conversely, if a single UDP flow was respons= ible for the congestion, it would let the other traffic bypass it. This is = why fq_codel is better than just plain codel, if you can get it.

- Jonathan Morton

--485b397dd6374dc711051052ec8d--