From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 DFF9121FD8D for ; Mon, 7 Sep 2015 15:31:53 -0700 (PDT) Received: by ykdu9 with SMTP id u9so17978938ykd.2 for ; Mon, 07 Sep 2015 15:31:52 -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=umk/2QZ890QqyTMV3+dRqbbWs3vPeI9dtG29jIJ0EKo=; b=t+DVmVy3tQwMFJubjQ8CSgCh29tbY1pWv04OeQcT+QW8r7T1elU4wbZzgVAOtMym9V DDm44Evb7/C+mYBR70i8IQfDep3jWFKe+M6gOaglSHf7MI8uWy8GPGD6mjXT3++4T6mJ 4fNOwehIwLuf6PGR9BLBwEz38bwiVa+MpvPnY1VwToHqTbCHhPXwYegp6kxJCLhoBGIc D57EDjah2MEQL0UPspn3U03St3IZNOVOa78zz9EugrqKP9cLyZM/bT5tG0goRdJ5LyKU 9YUPknTSiUlGG/9Mtf1BJkT8NdMMYDxuEcThmThOkOhef6pASZx6VMI1hczlJhHHJJdm tGvw== MIME-Version: 1.0 X-Received: by 10.129.53.194 with SMTP id c185mr16824168ywa.158.1441665112286; Mon, 07 Sep 2015 15:31:52 -0700 (PDT) Received: by 10.13.236.80 with HTTP; Mon, 7 Sep 2015 15:31:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Sep 2015 17:31:52 -0500 Message-ID: From: Benjamin Cronce To: Sebastian Moeller Content-Type: multipart/alternative; boundary=001a11421478e7307a051f2fd0e5 Cc: cake@lists.bufferbloat.net, Felix Fietkau Subject: Re: [Cake] cake work needed for openwrt merge X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 22:32:16 -0000 --001a11421478e7307a051f2fd0e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 7, 2015 at 3:35 PM, Sebastian Moeller wrote: > Hi Benjamin, > > On Sep 7, 2015, at 21:43 , Benjamin Cronce wrote: > > > If you're only concerned about the magnitude, fixed-line based Internet > connections only have two magnitudes. Local(10ms) and world-wide(100ms). = My > break down goes like this for datacenters from my home connection. > > 10ms Chicago > > 30ms New York City and Washington DC > > 45ms Houston and Miami > > 60ms San Jose and San Francisco > > 70ms LA, San Diego, and Seattle > > 90ms London and Paris > > 115ms Hawaii > > 120ms Frankfurt and Switzerland > > 150ms Japan > > 170ms Moscow > > 190ms New Zealand > > 210ms Sao Paulo(Brazil) > > 215ms Sydney > > 220ms Hong Kong and Dubai(United Arab Emirates) > > 250ms Singapore, China, India, Cape Town(South Africa) > > > > As you can tell, terrestrial latency doesn't have many flavors except > when congestion or horrible routing is involved. In my case, my 95th > percentile of high RTTs is around 20ms because of CDNs and my 80th is > closer to 10ms. Similar with video games, except Eve Online which is host= ed > in London. In my case, a 100ms RTT is from Hawaii to Europe. > > Good point, so it is rather =E2=80=9Clongest realistic RTT=E2=80= =9D what we are > after. My point was not about what the real RTTs are (even though your > results are interesting in themselves) but how to name the parameter to n= ot > confuse novice users=E2=80=A6 and my hunch is RTT is not the best descrip= tion here=E2=80=A6 > but I lack a better snappy phrase > > Best Regards > Sebastian > It may be easier to use a distance based naming. Instead of something like "High(250ms) RTT" be like "Inter-continental", medium(100ms) RTT may be "Intra-continental", and low(50ms) RTTs may be "Local Region". "Region" can be a bit ambiguous, but I figured if given two options "Local Region" and "Intra-continental", that the idea of what "region" represents in this context is clear enough. Satellite links would only need one option because the latency of the satellite will be greater than the latency from all of the terrestrial links combined. As for the actual variable name and not the option names. hmmm. Assuming similarly named options, "Optimize for"? > > > > > If you're only concerned about magnitudes, then only need a few options > like fixed-line terrestrial mode and satellite mode for your main options= . > If I was to choose a custom interval/RTT for myself without doing a prop= er > measurement, probably 40ms, assuming that gives any benefit over the > default 100ms > > > > On Mon, Sep 7, 2015 at 6:21 AM, Sebastian Moeller > wrote: > > Hi Dave, > > > > On Sep 7, 2015, at 12:45 , Dave Taht wrote: > > > > > ** expose the interval parameter for longer rtts. > > > > > > In fact, I think using the word "rtt" might be saner than "interval= =E2=80=9D. > > > > Not sure, RTT will make a lot of people nervous about this bein= g > basically a run-time constant while actual RTTs of the flows range from a > few ms to several 100s. To not confuse these people we would need somethi= ng > like =E2=80=9Ctypical average/median RTT=E2=80=9D or =E2=80=9Clongest rea= listic RTT=E2=80=9D or even > =E2=80=9Ccenter of realistic RTT range=E2=80=9D that conveys that this is= more about order > of magnitude than any real RTT. It could also be that people in general a= re > much better about this and I just got a specific subset in the crowd I tr= y > to help getting sqm-scripts up and running ;) > > > > > > Best Regards > > Sebastian > > > > > We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS. :) > > > > > > > > > On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht wrote= : > > >> In discussing with felix what is needed for cake to go into openwrt > > >> trunk, we came up with the following list: > > >> > > >> * Cake work needed > > >> ** Add squash option (besteffort + squashing diffserv) > > >> ** Fix diffserv > > >> ** Add man page > > >> ** Clean up patches to only do cake > > >> *** Reformat for kernel_style > > >> *** IProute patches for mainline iproute > > >> ** Submit as a single patch to openwrt for each > > >> ** cake patches goes into the openwrt iproute directly > > >> ** continues to be built externally as kmod-sched-cake > > >> ** Needs update to the new kernel hashing api > > >> ** Openwrt is stablizing for now, on linux 4.1 > > >> ** CC is essentially done, but there will a CC.1 release at some poi= nt > > >> ** Add better statistics (like active_flows) - have part of this > already > > >> > > >> > > >> -- > > >> Dave T=C3=A4ht > > >> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo > > > > > > > > > > > > -- > > > Dave T=C3=A4ht > > > endo is a terrible disease: http://www.gofundme.com/SummerVsEndo > > > _______________________________________________ > > > Cake mailing list > > > Cake@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/cake > > > > _______________________________________________ > > Cake mailing list > > Cake@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cake > > > > --001a11421478e7307a051f2fd0e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 7, 2015 at 3:35 PM, Sebastian Moeller <= ;moeller0@gmx.de&g= t; wrote:
Hi Benjamin,

On Sep 7, 2015, at 21:43 , Benjamin Cronce <bcronce@gmail.com> wrote:

> If you're only concerned about the magnitude, fixed-line based Int= ernet connections only have two magnitudes. Local(10ms) and world-wide(100m= s). My break down goes like this for datacenters from my home connection. > 10ms Chicago
> 30ms New York City and Washington DC
> 45ms Houston and Miami
> 60ms San Jose and San Francisco
> 70ms LA, San Diego, and Seattle
> 90ms London and Paris
> 115ms Hawaii
> 120ms Frankfurt and Switzerland
> 150ms Japan
> 170ms Moscow
> 190ms New Zealand
> 210ms Sao Paulo(Brazil)
> 215ms Sydney
> 220ms Hong Kong and Dubai(United Arab Emirates)
> 250ms Singapore, China, India, Cape Town(South Africa)
>
> As you can tell, terrestrial latency doesn't have many flavors exc= ept when congestion or horrible routing is involved. In my case, my 95th pe= rcentile of high RTTs is around 20ms because of CDNs and my 80th is closer = to 10ms. Similar with video games, except Eve Online which is hosted in Lon= don. In my case, a 100ms RTT is from Hawaii to Europe.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Good point, so it is rather =E2=80=9Clon= gest realistic RTT=E2=80=9D what we are after. My point was not about what = the real RTTs are (even though your results are interesting in themselves) = but how to name the parameter to not confuse novice users=E2=80=A6 and my h= unch is RTT is not the best description here=E2=80=A6 but I lack a better s= nappy phrase

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = Sebastian
=C2=A0
It may be eas= ier to use a distance based naming. Instead of something like "High(25= 0ms) RTT" be like "Inter-continental", medium(100ms) RTT may= be "Intra-continental", and low(50ms) RTTs may be "Local Re= gion". "Region" can be a bit ambiguous, but I figured if giv= en two options "Local Region" and "Intra-continental", = that the idea of what "region" represents in this context is clea= r enough. Satellite links would only need one option because the latency of= the satellite will be greater than the latency from all of the terrestrial= links combined. As for the actual variable name and not the option names. = hmmm. Assuming similarly named options, "Optimize for"?
=C2=A0

>
> If you're only concerned about magnitudes, then only need a few op= tions like fixed-line terrestrial mode and satellite mode for your main opt= ions. If I was to choose a=C2=A0 custom interval/RTT for myself without doi= ng a proper measurement, probably 40ms, assuming that gives any benefit ove= r the default 100ms
>
> On Mon, Sep 7, 2015 at 6:21 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> On Sep 7, 2015, at 12:45 , Dave Taht <dave.taht@gmail.com> wrote:
>
> > ** expose the interval parameter for longer rtts.
> >
> > In fact, I think using the word "rtt" might be saner th= an "interval=E2=80=9D.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Not sure, RTT will make a lot of peop= le nervous about this being basically a run-time constant while actual RTTs= of the flows range from a few ms to several 100s. To not confuse these peo= ple we would need something like =E2=80=9Ctypical average/median RTT=E2=80= =9D or =E2=80=9Clongest realistic RTT=E2=80=9D or even =E2=80=9Ccenter of r= ealistic RTT range=E2=80=9D that conveys that this is more about order of m= agnitude than any real RTT. It could also be that people in general are muc= h better about this and I just got a specific subset in the crowd I try to = help getting sqm-scripts up and running ;)
>
>
> Best Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian
>
> > We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS= . :)
> >
> >
> > On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >> In discussing with felix what is needed for cake to go into o= penwrt
> >> trunk, we came up with the following list:
> >>
> >> * Cake work needed
> >> ** Add squash option (besteffort + squashing diffserv)
> >> ** Fix diffserv
> >> ** Add man page
> >> ** Clean up patches to only do cake
> >> *** Reformat for kernel_style
> >> *** IProute patches for mainline iproute
> >> ** Submit as a single patch to openwrt for each
> >> ** cake patches goes into the openwrt iproute directly
> >> ** continues to be built externally as kmod-sched-cake
> >> ** Needs update to the new kernel hashing api
> >> ** Openwrt is stablizing for now, on linux 4.1
> >> ** CC is essentially done, but there will a CC.1 release at s= ome point
> >> ** Add better statistics (like active_flows) - have part of t= his already
> >>
> >>
> >> --
> >> Dave T=C3=A4ht
> >> endo is a terrible disease: http://www.gofundme.co= m/SummerVsEndo
> >
> >
> >
> > --
> > Dave T=C3=A4ht
> > endo is a terrible disease: http://www.gofundme.com/Su= mmerVsEndo
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbl= oat.net
> > https://lists.bufferbloat.net/listinfo/cake=
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.n= et
> https://lists.bufferbloat.net/listinfo/cake
>


--001a11421478e7307a051f2fd0e5--