From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 2405E3CB38 for ; Tue, 18 Aug 2020 00:16:01 -0400 (EDT) Received: by mail-lj1-x236.google.com with SMTP id t6so19867908ljk.9 for ; Mon, 17 Aug 2020 21:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ieWp7lzLlbYZzrcN6rcNGr+22n0Sa9Nsb5DJPx/CWhI=; b=ZcxLKYq4FdCiQ1vReR5tOcZdgEv8cyhZYugBsku9ss7wuHgJ9JhHsyjGbSrgMRW65G 5fpnuRldTi8gcsrC6sUHv3rYPn85gaYYgO9zea0CAcryfxAypnaEQu3vvmcCKo6f+ySN 9+mpK8UDsnCcfvMGl4+1eUf4MNIDuDNtBBOPBekOMUOc1iJGNv8W4vwys7s18avqnU9S ityryxY7KAFZedjOLHIvEuJGKL5EfNp2BkQGT2AaEVo8oiF16UpUb2HF+hQ9Uqk3N8OH xWa1wjtsu5iflvOyz+2JNGfMavd2nfzvRqmEqCEnFdxwlT1fi62jFC5aNv2LSC8FYfBw x/mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ieWp7lzLlbYZzrcN6rcNGr+22n0Sa9Nsb5DJPx/CWhI=; b=CeWFOQENzIr0XCK5Vw1QNbmR7XLl7YSUUraAClxyXiN2iXrw3r5jsB304ekPCJoYp8 AzKEBALmkoUwXvVOCFPEdfjy8dEC4InzR0K1ZrePS0RGs0Xu/cfG1tXke57fzYdM1eDg ltaVWHBKgi2rAufMJTYSQ7vjLFtQ/YAIw4fGwYvO5Oev6LYiN0ySlnec5W27ZzPEWphE bhevKDBRIA51XtaWNIXoBg0HMGH7Lu7tc3bHry8pUwH1uQJiPnl4kirrler/TogQetj3 ybFooJF272DpeUeZ95w8sYO/zwH5VtEz4gZihTl4Cv0umDoElDXb+m9rW+HnJ92wzhjO Ul/A== X-Gm-Message-State: AOAM531xZjcMCD42t4YbYy1fCcVmzIMpEispBfRmct+4dAN5xWW9EeHF nNMyj/wFMQzZ/PdvJfPR6W1rKeWfi6fUcw== X-Google-Smtp-Source: ABdhPJzw7UbA6OtA6DsN7IDHn5qEN2dHaQByBKiShmzK4Xo7N0MU+kCErR8AHtB1YNJKQeIOW2vXkQ== X-Received: by 2002:a05:651c:1041:: with SMTP id x1mr8209964ljm.169.1597724159503; Mon, 17 Aug 2020 21:15:59 -0700 (PDT) Received: from [192.168.7.121] (178-55-224-121.bb.dnainternet.fi. [178.55.224.121]) by smtp.gmail.com with ESMTPSA id z22sm6039626lfb.93.2020.08.17.21.15.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Aug 2020 21:15:58 -0700 (PDT) To: bloat@lists.bufferbloat.net References: From: Jonathan Morton Message-ID: <530c76a4-d51f-29d0-c9de-2a7ba70de664@gmail.com> Date: Tue, 18 Aug 2020 07:15:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] cake + ipv6 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 04:16:01 -0000 On 18/08/2020 06:44, Daniel Sterling wrote: > ...is it possible to identify (and thus classify) > plain old bulk downloads, as separate from video streams? They're both > going to use http / https (or possibly QUIC) -- and they're both > likely to come from CDN networks... I can't think of a simple way to > tell them apart. If there was an easy way to do it, I would already have done so. We are unfortunately hamstrung by some bad design and deployment around Diffserv, which might otherwise provide a useful end-to-end visible signal here. > Is this enough of a problem that people would try to make a list of > netblocks / prefixes that belong to video vs other CDN content? It's possible that someone is doing this, but I don't specifically know of such a source of information. It would of course be better to find a solution that didn't rely on white/black lists, which have a distressing habit of going stale. But one of the more reliable ways might be to use Autonomous System (AS) information. ASes are an organisational unit used for assigning IP address ranges and for routing, and usually correspond to a more-or-less significant Internet organisation. It should be feasible to map an observed IP address to an AS, then look up the address blocks assigned to that AS, thereby capturing a whole range of related IP addresses. > I do notice video streams are much more bursty than plain downloads > for me, but that may not hold for all users. > > That is, for me at least, a video stream may average 5mbps over, say, > 1 minute, but it will sit at 0mbps for a while and then burst at > 20mbps for a bit. Correct, YouTube at least likes to fetch a big block of data from disk and send it all at once, then rely on the client buffer to tide it over while the disk services other requests. It makes some sense when you consider how slow disk seeks are relative to the number of clients they need to support, each of which will generally be watching a different video (or at least a different part of the same one). However, this burstiness disappears on the wire just when you would like to use it to identify traffic, ie. when the video traffic saturates the bandwidth available to it. If there's only just enough bandwidth, or even *less* than what is required, then YouTube sends data continuously into the client buffer, trying to keep it as full as possible. There are no easy answers here. But I've suggested some things to look for and try out. - Jonathan Morton