From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 64DC821F416 for ; Tue, 16 Jun 2015 11:30:04 -0700 (PDT) Received: by oial131 with SMTP id l131so17655091oia.3 for ; Tue, 16 Jun 2015 11:30:03 -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:content-transfer-encoding; bh=qC4C5gAs8ufjtB08kOhpOZ5b2DgK3FZDzihmKrhKLPo=; b=Iri8eeTihoNp7KkAWxt01381idBb4B1wOw/wN/QZsU7X8ct8oDToMCt7p/N6k8pgsD 7Yqh2gfdvKUYl9vgVtMY06fD5Sr2YTi8ZnoUHuO1UwdLnt5C7Dd8iiLwKwacVHuuh1jT YpTOtmjzzrufqK3gvTAjx7wpnDp2ZfBmNZwTxu4Au6+szz23VB36hladnAzaokmn+ECp TH3VIo9S60sDuyA5XAlP8x2kWD54JiHApTVzVTtRFPB8MFN9jUF36FgL8kvwmN22PsK/ SZ67JjPOqVsrZcVshKX537FiYw4xwlCXR5H3VNDlGPfBWgQM/+EwfBmWVxvp1o40Soic H/zw== MIME-Version: 1.0 X-Received: by 10.202.71.20 with SMTP id u20mr1255466oia.81.1434479403044; Tue, 16 Jun 2015 11:30:03 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Tue, 16 Jun 2015 11:30:02 -0700 (PDT) In-Reply-To: <17A671BF-59B9-41B2-B629-FFB211A134F4@gmx.de> References: <17A671BF-59B9-41B2-B629-FFB211A134F4@gmx.de> Date: Tue, 16 Jun 2015 11:30:02 -0700 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] Fwd: sweeping up the bloat 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: Tue, 16 Jun 2015 18:30:33 -0000 On Tue, Jun 16, 2015 at 11:10 AM, Sebastian Moeller wrote= : > Dear list, > > it seems my reply-all skill got a bit rusty, so here I go again ;) (threa= ding might be broken?) > > On Jun 16, 2015, at 19:53 , Dave Taht wrote: > >> [...] >> Quic does pacing, so far as I know, entirely in userspace, or does it >> rely on sch_fq to do so? Should a VOIP app or server like freeswitch >> use it? > [=E2=80=A6] > > I thought a voip app will pace simply by virtue of having to collect 10-2= 0ms seconds worth of audio before packing this up and send it off. I have n= ot looked at packet captures but my H0 is that there should be one UDP pack= et every 20ms, which I would call natural or data-driven pacing. I would no= t be too amazed if in reality instead of 1 packet per 20ms the app would se= nd N packets every N*20ms; sad, yes, but not amazed. Kind of massively off the general topic of finding more low hanging fruit: Well, our recommendation 3 years ago to the freeswitch folk was more minimal buffering in the qdisc and fq_codel.[1] As we are well aware this is stochastic fq, not full blown fq, and sch_fq was largely targeted at tcp apps and has (had) some worrisome behaviors with udp traffic and synfloods. Many voip providers carry 1000s or 10s of thousands of simultaneous conversations. Arguably a sch_fq like qdisc that just dropped all but the newest packet in a flow might be of use. Voip is also carried over tcp in some cases. voip servers DO use tcp for things like backups and C&C. Voip service providers also commonly used tcp-vegas, last I looked. CDG is looking quite promising. How should they do tcp whilst serving voip? webrtc is getting *widely* deployed and video frames, spread across packets, have different characteristics than voip does, which we have never fully explored in test (works DARN well in actual use, but could it be better? I liked the old NADA ecn proposal for i-frames in particular). Although it can be a server based application (what should a server look like) it is also (hopefully) a p2p app. Are the browsers pacing? Last I recall webrtc was sending a 16k or more burst. Should a host enforce pacing in the lower levels of the stack? How well does videoconferencing aggregate over wifi in each direction? Apps like freeswitch/asterisk and conference servers and so on are all moving fast to HD, extremely high rate/resolution (by previous standards) videoconferencing, which has issues with ramping up with tcp_friendly behavior. Some conferencing apps are completely ignoring tcp_friendly behavior... (I note the cluecon folk wanted a bufferbloat talk in august and I keep hoping someone will go do that.) [1] can't find the webpage on this > > Best Regards > Sebastian > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast