From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (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 1937821F413; Fri, 12 Jun 2015 22:50:13 -0700 (PDT) Received: by yhid80 with SMTP id d80so20570244yhi.1; Fri, 12 Jun 2015 22:50:13 -0700 (PDT) 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=Jlmz9s1CC/Xbh9lUM/fyTR6qs8Bwwe+vEj6vDzvgog8=; b=ikEZaMgmBSWLow/DPnX0XpU8P1vyC4wuCr2XNeneEwy17OleFCOt0701+EIImJFedl 7TUC7kgTTMppJOnKbDn/b8Uk3qIEcydX73rzKWo7/5gru05/Mzdh1i68gfsQOCELPu6Z p1Nxy+YWNU7LOoTTlJWL9F6UrIJaiajHY531ospMF4kf7CZzUAItkJiRanizep0APhXV c8wVmAUtIcDylFZM5HT7j9SmiXzGmhJ6C3NfI8J0PE3ewpnpkIZ2ge07TzMhuEjYc/Ro 0k8jvMM4Mdaa7QFV5rJ/IO8/8ssPmy9E1wLZow/xSn6HyTjDLsrYHmKAEmv3+MHPCZcI FgyQ== MIME-Version: 1.0 X-Received: by 10.170.171.130 with SMTP id n124mr22642088ykd.100.1434174613160; Fri, 12 Jun 2015 22:50:13 -0700 (PDT) Received: by 10.129.148.194 with HTTP; Fri, 12 Jun 2015 22:50:13 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Jun 2015 00:50:13 -0500 Message-ID: From: Benjamin Cronce To: David Lang Content-Type: multipart/alternative; boundary=001a113a54f45d0b4405185fccd3 Cc: cake@lists.bufferbloat.net, Daniel Havey , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Cake] active sensing queue management X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 05:50:43 -0000 --001a113a54f45d0b4405185fccd3 Content-Type: text/plain; charset=UTF-8 On Fri, 12 Jun 2015, Daniel Havey wrote: > > > On Thu, Jun 11, 2015 at 6:49 PM, David Lang wrote: > >> On Wed, 10 Jun 2015, Daniel Havey wrote: > >> > >>> We know that (see Kathy and Van's paper) that AQM algorithms only work > >>> when they are placed at the slowest queue. However, the AQM is placed > >>> at the queue that is capable of providing 8 Mbps and this is not the > >>> slowest queue. The AQM algorithm will not work in these conditions. > >> > >> > >> so the answer is that you don't deploy the AQM algorithm only at the > >> perimeter, you deploy it much more widely. > >> > >> Eventually you get to core devices that have multiple routes they can use to > >> get to a destination. Those devices should notice that one route is getting > >> congested and start sending the packets through alternate paths. > >> > >> Now, if the problem is that the aggregate of inbound packets to your > >> downstreams where you are the only path becomes higher than the available > >> downstream bandwidth, you need to be running an AQM to handle things. > >> > >> David Lang > >> > > > > Hmmmm, that is interesting. There might be a problem with processing > > power at the core though. It could be difficult to manage all of > > those packets flying through the core routers. > > And that is the question that people are looking at. > > But part of the practical question is at what speeds do you start to run into > problems? > > the core of the Internet is already doing dynamic routing of packets, spreading > them across multiple parallel paths (peering points have multiple 10G links > between peers), so this should be more of the same, with possibly a small > variation to use more expensive paths if the cheap ones are congested. Yes and no. Spreading data across parallel links is mostly done at the MAC layer and does not show up as separate routes, thinking teaming ports for Ethernet. Routing is dynamic, but typically takes a bit for the route changes to propagate. For the most part, you can only control where you send data, but not where you receive it. The core of the Internet typically only has 2-3 routes to choose from with one primary route and the other only used for fail over. Load balancing asymmetrical routes is a very messy issue that you really don't want to do. Most of the time, the cheapest route is also the fastest. If you had to choose between a $5k/month 100Gb port at a peering location or a $30k 10Gb transit link, I'm sure you won't be doing any load balancing over the 10Gb link unless your 100Gb failed. Routes really don't change that often. You have a default transit route and a bunch of peering routes. The peering routes take priority because they're cheaper and the transit route is for when bad things happen or you just don't have peering for that route. In the case of my ISP, everything is transit, let Level 3 worry about peering. > But as you move out from there towards the edge, the packet handling > requirements drop rather quickly, and I'll bet that you don't have to get very > far out before you can start affording to implement AQM algorithms. I'm betting > that you reach that point before you get to the point in the network where you > no longer have multiple paths available > > > David does bring up an interesting point though. The ASQM algorithm > > was originally designed to solve the "Uncooperative ISP" problem. I > > coined the phrase, but, you can fill in your own adjective to fit your > > personal favorite ISP :^) > > > > The paper doesn't indicate this because I got roasted by a bunch of > > reviewers for it, but, why not use an ASQM like algorithm other places > > than the edge. Suppose you are netflix and your ISP is shaping your > > packets? You cant do anything about the bandwidth reduction, but, you > > can at least reduce the queuing...Just food for thought. :^) > > unfortunantly if you are trapped by the ISP/netflix peering war, you reducing > the number of packets in flight for yourself isn't going to help any. It would > have to happen on the netflix side of the bottleneck. > > David Lang > --001a113a54f45d0b4405185fccd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, 12 Jun 2015, Daniel Havey wrote:
&g= t;=C2=A0
> > On Thu, Jun 11, 2015 at = 6:49 PM, David Lang <david at lang.hm>= wrote:
> >> On Wed, 10 Jun 2015, = Daniel Havey wrote:
> >>
> >>> We know that (see Kathy and Van= 9;s paper) that AQM algorithms only work
&g= t; >>> when they are placed at the slowest queue.=C2=A0 However, t= he AQM is placed
> >>> at the q= ueue that is capable of providing 8 Mbps and this is not the
> >>> slowest queue.=C2=A0 The AQM algorithm = will not work in these conditions.
> >= ;>
> >>
> >> so the answer is that you don't deploy the AQM a= lgorithm only at the
> >> perimete= r, you deploy it much more widely.
> >= ;>
> >> Eventually you get to c= ore devices that have multiple routes they can use to
> >> get to a destination. Those devices should notice = that one route is getting
> >> con= gested and start sending the packets through alternate paths.
> >>
> >&= gt; Now, if the problem is that the aggregate of inbound packets to your
> >> downstreams where you are the o= nly path becomes higher than the available
= > >> downstream bandwidth, you need to be running an AQM to handle= things.
> >>
> >> David Lang
> &= gt;>
> >
> > Hmmmm, that is interesting.=C2=A0 There might be a problem= with processing
> > power at the cor= e though.=C2=A0 It could be difficult to manage all of
> > those packets flying through the core routers.
<= div class=3D"gmail_extra">>=C2=A0
> A= nd that is the question that people are looking at.
>=C2=A0
> But part of the pr= actical question is at what speeds do you start to run into=C2=A0
> problems?
>= =C2=A0
> the core of the Internet is alr= eady doing dynamic routing of packets, spreading=C2=A0
> them across multiple parallel paths (peering points have m= ultiple 10G links=C2=A0
> between peers)= , so this should be more of the same, with possibly a small=C2=A0
> variation to use more expensive paths if the ch= eap ones are congested.

Yes and no. Spreading data across parallel links is mostl= y done at the MAC layer and does not show up as separate routes, thinking t= eaming ports for Ethernet. Routing is dynamic, but typically takes a bit fo= r the route changes to propagate. For the most part, you can only control w= here you send data, but not where you receive it. The core of the Internet = typically only has 2-3 routes to choose from with one primary route and the= other only used for fail over. Load balancing asymmetrical routes is a ver= y messy issue that you really don't want to do. Most of the time, the c= heapest route is also the fastest. If you had to choose between a $5k/month= 100Gb port at a peering location or a $30k 10Gb transit link, I'm sure= you won't be doing any load balancing over the 10Gb link unless your 1= 00Gb failed.

Routes really don't change that often. You have a default transi= t route and a bunch of peering routes. The peering routes take priority bec= ause they're cheaper and the transit route is for when bad things happe= n or you just don't have peering for that route. In the case of my ISP,= everything is transit, let Level 3 worry about peering.
=C2=A0
> But as you move o= ut from there towards the edge, the packet handling=C2=A0
> requirements drop rather quickly, and I'll bet th= at you don't have to get very=C2=A0
>= ; far out before you can start affording to implement AQM algorithms. I'= ;m betting=C2=A0
> that you reach that p= oint before you get to the point in the network where you=C2=A0
> no longer have multiple paths available
>=C2=A0
> >= David does bring up an interesting point though.=C2=A0 The ASQM algorithm<= /div>
> > was originally designed to solve = the "Uncooperative ISP" problem. =C2=A0I
> > coined the phrase, but, you can fill in your own adjectiv= e to fit your
> > personal favorite I= SP :^)
> >
> > The paper doesn't indicate this because I got roasted b= y a bunch of
> > reviewers for it, bu= t, why not use an ASQM like algorithm other places
> > than the edge.=C2=A0 Suppose you are netflix and your ISP= is shaping your
> > packets?=C2=A0 Y= ou cant do anything about the bandwidth reduction, but, you
> > can at least reduce the queuing...Just food for = thought. :^)
>=C2=A0
> unfortunantly if you are trapped by the ISP/netflix peeri= ng war, you reducing=C2=A0
> the number = of packets in flight for yourself isn't going to help any. It would=C2= =A0
> have to happen on the netflix side= of the bottleneck.
>=C2=A0
> David Lang
>=C2= =A0
--001a113a54f45d0b4405185fccd3--