From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 58B993B2A0 for ; Fri, 10 Jun 2016 08:44:02 -0400 (EDT) Received: by mail-wm0-x236.google.com with SMTP id n184so265272795wmn.1 for ; Fri, 10 Jun 2016 05:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=nXnLHoURFvv49z5GMSV21UXCnRf+rznUExsvWZXag3g=; b=eJIZy1eCYxiVvs+siE7c2QmkFVMD8KI0h/boHUG/uowfMM82AR+3FS6KHZXArQKWUt TqaUMPcN2RvmD1s1ZfSuXrbLP5wPMoPfLpio+NpIJVn2MQrtk2L21fBQwRTZyJhXelJd 8fS87mOOykoYpdw4lmiuA1speG2yCHfNmf4fW6rgRbsIhKqDEXrZ7i0n/gbuN2eMlis8 +OImQxk/I0gyN5ApjBiTxk+vastvCOuyEQCTjmLjFzsKSFwrjFxgoyRIC4E4zBmK8R9I b1rfipXa/IXunP7r+xGgzQZdEj8TV943egDSz7kYLNw78VvF3X3VgKwzOjBQ/nri/k21 qx5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nXnLHoURFvv49z5GMSV21UXCnRf+rznUExsvWZXag3g=; b=AEP8JAei1nPFYO6HxyxITrXAcjBPj1mgDl8xe0AMWqsyi1RZtMPcIa/PJqxxnD83qo Lxn6iUUjxbZn5dzp5TwGUEeCU6Zd8Ij9ouMt2c2niOhuU+MtXsSKZUjXexO1dcLz5ALK nATl3qxpk00Iz+zX0MA8qGnyDVARVFKO+wE0UD4qDyInb7peuwdjKBJ1eA782lrnGJmI cHOLTMm7gwbUfoGYFDg9/pe7A0xFnBdFse0ShO+CcMgTd+21g6SOBs7uzJrXzJDICG/S 8nX5grfz7RY4X0ECBYc2otzBewXoYYbJ3+gVXBLISYr/hvtijtDnYJqa77OzjrEAwG75 y7Rw== X-Gm-Message-State: ALyK8tILz0xqRNDOioyuS22DK9f9UPqPmnBe0IXhKolPDLPN9ztgyHK+Poud2HZlUDhL6g== X-Received: by 10.28.26.67 with SMTP id a64mr2749798wma.70.1465562641112; Fri, 10 Jun 2016 05:44:01 -0700 (PDT) Received: from [192.168.0.1] (ip-109-90-29-200.hsi11.unitymediagroup.de. [109.90.29.200]) by smtp.gmail.com with ESMTPSA id u70sm25749005wmd.4.2016.06.10.05.44.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 05:44:00 -0700 (PDT) References: <7409a52d-8c81-25f0-e070-c7638fdf9d83@gmail.com> <0B4652E3-F061-479D-8BB3-EA0193333A51@gmx.de> <3d4cdbf4-42dd-a371-2d44-f1bad6505684@gmail.com> To: moeller0 Cc: cake@lists.bufferbloat.net From: Dennis Fedtke Message-ID: <735b7505-584f-6c94-2047-110254e73ee8@gmail.com> Date: Fri, 10 Jun 2016 14:43:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] New to cake. Some questions X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 12:44:02 -0000 Hi Sebastian, i used the default setting of 1000. But it seems that my isp is dropping icmp packets if there are exceeding = some sending threshold. So there is a lot of none usable ping data. I increased the send delay=20 to 50ms. 25 ms already shows dropped requests. This is the third run now. Waiting for completion. The ping target is my first hop. Actually my ping always varies around +-5ms even at idle and=20 independently of ping target. When i look through the ping file the increase in ping times are=20 actually appear to be random to me. So how to test if my isp responses with fixed icmp packet size? Im in central europe too :D Thanks :) Am 10.06.2016 um 07:20 schrieb moeller0: > Hi Dennis, > > >> On Jun 10, 2016, at 02:49 , Dennis Fedtke wro= te: >> >> Hi Sebastian, >> >> Sorry this is positive or? > I would say that is unclear=E2=80=A6 > >> But i need more samples ? > I would try with more samples, after checking that the ping times in t= he recorded data file actually are larger for larger probes than for smal= ler, some hosts will reply with a fixed maximum ICMP packet instead of re= turning the received packet, thereby reducing the signal range (as only t= he upload leg of the link is meaning fully contributing useful differenti= al signal. > BTW I am in central europe so at times of the day my responses can be = very sporadic, as I either am at work or sleeping ;) > > Best Regards > Sebastian > >> Thanks :) >> >> >> Am 10.06.2016 um 01:11 schrieb moeller0: >>> Hi Dennis, >>> >>>> On Jun 10, 2016, at 00:45 , Dennis Fedtke w= rote: >>>> >>>> Hi Sebastian, >>>> >>>> thank you for your answers :) >>>> >>>> The ATM overhead detector script is currently running. >>>> I read the wiki about it but im not quite sure how to interpret the = plot. >>>> I mean what info should i read from it? maximum packet size? >>> The relevant number is reported as =E2=80=9CEstimated overhead prece= ding the IP header=E2=80=9D in the top part of the second figure created = by the script. But that is only relevant.useful if you see a nice step li= ke plot in figure 2 as well ( the second figure in https://github.com/moe= ller0/ATM_overhead_detector/wiki as positive and the fourth figure as neg= ative example. >>> >>>> If yes do i set the overhead in cake? Or do i set iptables to clamp = to new mtu/mss? >>> If you use plain cake and you know the numerical overhead (NN) the e= asiest is to add the following to your cake invocation: =E2=80=9Catm over= head NN=E2=80=9D >>> >>> Please note that if you use cake on an ethernet interface the kernel = will already account for 14 byte of ethernet overhead, so if the script t= old you 44 as actual overhead, you use =E2=80=9Doverhead 30=E2=80=9D to a= ddress that. If you use a pppoe interface the kernel will most likely not= add the 14 bytes for you, so then you would use =E2=80=9Coverhead 44=E2=80= =9D (I excluded the atm option in the last examples for clarity=E2=80=A6)= >>> >>>> Regarding UDP paket dropping problem: >>>> I just read some forums and users stated that under heavy load cake = starts to drop udp packets which causes lag ingame. >>>> My idea was to set ingress/egress to diffserv4 and apply the EF dscp= mark on those packets. >>> Ell, not a bad idea, but often the problem are in the incoming traff= ic, and unfortunately with the ifb we use we can not use iptables, but on= ly tc, and remarking with tc is unpleasant. >>> >>>> Will this even work? if yes how to do this? iptables? >>> No, you wuld need tp use tc. >>> >>>> ipt -t mangle -A PREROUTING -p udp -m multiport --ports 5000:5500 -j= DSCP --set-dscp-class EF >>>> >>>> Like thia? Is prerouting correct here? (Taken from layer cake script= ) >>> This will affect outgoing packets and might be a good idea in your s= pecific case. >>> >>> BUT why don=E2=80=99t you try the default behaviour with specific rul= es and tricks and report success or failure back to us, after all the fas= test/easiest classification is one one does not need to perform at all. >>> >>>> For the squash and wash feature. >>>> Im asking because if i choose to squash in the advanced options of s= qm scripts. >>>> The dscp fields/marks will be overwritten by iptables to 0 (besteffo= rt). (layer cake script) >>>> So then it makes no sense to manually set dscp fields/marks or? (Or = even setting diffserv) >>> No unfortunately on ingress cake sees the packets before iptables, s= o the effective behavioral emulation of wash/squash by cake is to set ing= ress cake to besteffort (basically cake ignores the dscp field which func= tionally is identical to all packets having the same value). The squashin= g by iptables just clears the dscp marls so that internal networking elem= ents like potentially wifi liknks are not confuzed by the dscp informatio= n. >>> >>>> Did i understand this correctly. Per rfc isps should not provide dsc= p fields/marks? >>> Not exactly, per RFC DSCPs are only ever valid/defined inside a DSCP= domain and your ISPs domain ends before it reaches your CPE. Since you h= ave no control over your ISPs markings, they can be very much not like yo= u want them to be (Dave That reported that his ISP re-mapped almost 1/3 o= r so of packets into the CS1 background class). So it is recomended that = each DSCP domain re-mapps the code points at its entry point, which in yo= ur case is your router=E2=80=A6 >>> >>> Best Regards >>> Sebastian >>> >>>> Thank you. >>>> >>>> >>>> >>>> Am 09.06.2016 um 23:30 schrieb moeller0: >>>>> Hi Dennis, >>>>> >>>>> let me start with a disclaimer, I am not the best information sourc= e for cake on this mailing list, but I assume the others will chime in if= I say something questionable=E2=80=A6 >>>>> >>>>>> On Jun 9, 2016, at 22:58 , Dennis Fedtke = wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> Currently im running lede + cake + sqm_scripts and i have some que= stions: >>>>>> >>>>>> 1. What is considered the =E2=80=9Coptimal" setup atm for cake? >>>>> The same as without cake; really, proper per-packet-overhead accou= nting is important for bandwidth shaping, especially for ATM -based links= =2E I would recommend to follow the method on https://github.com/moeller0= /ATM_overhead_detector to m\empirically measure whether your link uses AT= M encapsulation and what exact overhead is in use. >>>>> >>>>>> e.g. which cake script should i use piece or layer cake? >>>>> piece_of_cake has only one tier of priority, while layer_cake curr= ently offers 4. Packets are put into the different priority bands based o= n the content of their TOS/DSCP filed in the IP header; if this is greek = to you, I guess piece_of_cake most likely is what you are looking for.. >>>>> >>>>>> 2. Recently squash and wash was removed. >>>>>> But the sqm scripts were not updated. In the advanced options shou= ld i set that the dcsp marks are kept? >>>>> This really is an implementation detail that has no immediate effe= ct if you choose piece_of_cake as typically only the bottleneck is sensit= ive to DSCP based priority banding. (Typically in that if you are unlucky= your WLAN will use the DSCP marks to move packets into 4 different prior= ity classes, which is fine if you want that, but bad for not sanity check= ed packets coming in from the wider internet (one is not supposed to assu= me incoming packets have sensible dscp markings as per RFC) that is why t= he wash/squash option is missed by some of us, independent of the fact th= at it was a layering violation). >>>>> >>>>>> 3. Should i use advanced options in sqm scripts and set triple-iso= late + diffserv8 ? >>>>> If you understand what these options do and believe that this is t= he best for your network go ahead, otherwise=E2=80=A6 The triple-isolate = option will try to be fair to host_IP addresses first and then for each h= ostIP fair to each flow, but for that to do something you will most likel= y want this requires that cake sees internal IP addresses of your end-hos= ts. In the typical configuration with SQM on the WAN interface of a NAT r= outer all internal addresses are replaced with the external IP address of= the router it self and triple-isolates per host fairness will pretty muc= h be equal to per flow fairness (not exactly, but in essence). So if you = want to try tiple-isolate or its better defined brothers dual-srchost and= dual-dsthost you would need to instantiate SQM on an internal interface = like LAN. But then the direction of ingress and egress from the routers p= erspective changes with regards to the internet download and upload direc= tion and you will need to put the internet upload bandwidth into the down= load field of the sqm GUI and vice versa. Also SQM on an internal interfa= ce will also shape internal traffic over the same interface, and that oft= en affects traffic to and from the wifi/wlan radios to the lan switch=E2=80= =A6 (I guess you would have preferred a shorter less vague response, but = such are the constraints=E2=80=A6) >>>>> >>>>>> 4. Is it recommend to enable diffserv on ingress? >>>>> If you trust/konw/have confirmed that your upstream (ISP?) sends y= ou sensible and reasonable DSCP markings by all means enable diffserv on = ingress. But the default assumption should be that your upstream used a d= scp mapping that only makes sense for them and not for you. >>>>> >>>>>> 5. Is there still the udp packet dropping problem? e.g. games that= are using udp. >>>>>> If yes does it make sense to apply diffserv classes manually? How = to do this? >>>>> I am not sure what you mean, but if you test this and have some fi= ndings please report here=E2=80=A6 >>>>> >>>>>> 6. is the autorate_ingress still under development? >>>>>> This very interesting feature. especially for docsis networks. Wil= l it be possible to set target ping time? >>>>> The last tests did indicate that this feature is not ready for pri= metime at least not on typically fixed bandwidth links and I assume docsi= s links are fixed enough. >>>>> >>>>>> 6. What difference does it make to set a different rtt? >>>>>> Setting lower rtt will reduce download speed i guess but will it a= llow better ping times (because of lower downloadrate uh)? >>>>>> What happens if rtt is set way higher? >>>>> With the RTT parameter you in essence specify how much time you gi= ve the endpoints of a flow to respond to a congestion signal (ECN marking= or packet drop) if you select this way to small you will sacrifice bandw= idth, if you set this too high you will accumulate more latency under loa= d. The good thing seems to be that this does not need to be terribly prec= ise, order of magnitude correctness seems to be sufficient (at least in b= ase2) >>>>> >>>>> >>>>>> Thank you! >>>>> I am sure the real experts will also chime in=E2=80=A6 >>>>> >>>>> Best Regards >>>>> Sebastian >>>>> >>>>>> _______________________________________________ >>>>>> 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 >>