From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "alln-iport.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8762221F1AA for ; Sun, 15 Dec 2013 13:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4711; q=dns/txt; s=iport; t=1387143735; x=1388353335; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WPN4NGw5/3HLxJ/RXkwU+ljiABUzFakg1BbfqR2wdiI=; b=iIXL2Oxq2GpIorAV7nHhZiTjxvFSmXjQ/Aa7Z5ayYuC4zvu0HZzCL3JN JTQVMDleB5u/T4R4Z956l1c5/Trp1TX/UscgAc5aWAjaUVPrR/AMrr6F1 ilz42RY4OIgD9E1s9vFCT0JBgraEe9vOPV8EOMplacMr3iWR7gcQyZt+2 o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAPcgrlKtJV2Y/2dsb2JhbABZgwo4VbhkgRoWdIIlAQEBAgEBeQULAgEIRiERJQIEDgUJBYdiAwkIDcAfDYcBF40GgTIJWAeDI4ETBJAzgTGER4FrjFqFOoMqgWgBHwQe X-IronPort-AV: E=Sophos;i="4.95,490,1384300800"; d="asc'?scan'208";a="6914182" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 15 Dec 2013 21:42:14 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBFLgEY8016434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Dec 2013 21:42:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sun, 15 Dec 2013 15:42:14 -0600 From: "Fred Baker (fred)" To: Naeem Khademi Thread-Topic: [aqm] What is a good burst? -- AQM evaluation guidelines Thread-Index: AQHO+d6DGaO57DEGIE2Y+PGzjUVmZQ== Date: Sun, 15 Dec 2013 21:42:12 +0000 Message-ID: <9660C545-473C-4039-AB42-A12B7C761FC8@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_0D503F3D-FA31-4119-AD12-2565EFEDF94D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "aqm@ietf.org" , bloat Subject: Re: [Bloat] [aqm] What is a good burst? -- AQM evaluation guidelines 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: Sun, 15 Dec 2013 21:42:15 -0000 --Apple-Mail=_0D503F3D-FA31-4119-AD12-2565EFEDF94D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 14, 2013, at 9:35 PM, Naeem Khademi = wrote: > Hi all=20 >=20 > I'm not sure if this has already been covered in any of the other = threads, but looking at = http://www.ietf.org/proceedings/88/slides/slides-88-aqm-5.pdf and = draft-ietf-aqm-recommendation-00, the question remains: "what is a good = burst (size) that AQMs should allow?" and/or "how an AQM can have a = notion of the right burst size?".=20 >=20 > and how "naturally-occuring bursts" mentioned in = draft-ietf-aqm-recommendation-00 can be defined?=20 Imagine, if you will, that you have a host and a network in front of it = including a first hop switch or router.The host gas a TCP offload = engine, which is a device that accepts a large chunk of data and sends = as much of it as it has permission to send as quickly as it can. The = host has, for sake of argument, a 10 MBPS interface, and everything else = in the network has interfaces whose rate are measured in gigabits. The = host gives its TSO one chunk of data, so that can't be called a "burst" = - it's one message. The TSO sends data as quickly as it can, but = presumably does little more than keep the transmission system operating = without a pause; while it might queue up 45 messages at a crack, there = is no requirement that it do so, so the term "burst" there doesn't have = a lot of meaning. And as the data moves through the network, the rate of = the particular session is absolutely lost in the available capacity. So = a burst, in the sense of the definition, never happens. Now, repeat the experiment. However, in this case the host as a gig-E = interface, and the next interface that its router uses is 10 or 100 = MBPS. The host and its TSO, and for that matter the router, do exactly = the same thing. As perceived by the router, data is arriving much more = quickly than it is leaving, resulting in a temporarily deep queue. If = the propagation delay through the remainder of the network and the = destination host are appropriate, acknowledgements could arrive at the = TSO, soliciting new transmissions, before that queue empties. In that = case, it is very possible that the queue remains full for a period of = time. This network event could last for quite some time. The second is clearly a burst, according to the definition, and I would = argue that it is naturally occurring. I imagine you have heard Van and/or Kathy talk about "good queue" vs = "bad queue". "Good queue" keeps enough traffic in it to fully utilize = its egress. "Bad queue" also does so, but does so in a manner that also = materially increases measured latency. This difference is what is behind = my comment on the objective of a congestion management algorithm (such = as TCP's but not limited to it) that its objective is to keep the amount = of data outstanding large enough to maximize its transmission rate = through the network, but not so large as to materially increase measured = latency or probability of loss.=20 I would argue that this concept of "Good Queue" is directly relevant to = the concept of an acceptable burst size. In the first transmission in a = session, the sender has no information about what it will experience, so = it behoves it to behave in a manner that is unlikely to create a = significant amount of "bad queue" - conservatively. But it by definition = has no numbers by which to quantify that. Hence, we make recommendations = about the initial window size. After that, I would argue that it should = continue to behave in a manner that doesn't led to "bad queue", but is = free to operate in any manner that seeks to keep the amount of data = outstanding large enough to maximize its transmission rate through the = network, but not so large as to materially increase measured latency or = probability of loss. At the point that it sends data in a manner that = creates a sustained queue, it has exceeded what would be considered a = useful burst size. --Apple-Mail=_0D503F3D-FA31-4119-AD12-2565EFEDF94D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSriIybjEdbHIsm0MRAjAnAKDcPMUZ6cLX7XF/E+AddGlxBtUykACfUozs mjOeX4kJYvHOF8N9wzSu2Tw= =nsMl -----END PGP SIGNATURE----- --Apple-Mail=_0D503F3D-FA31-4119-AD12-2565EFEDF94D--