Re: [Bloat] cake + ipv6

[Sebastian Moeller <moeller0@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 4169 bytes --]

Hi there,

A few related thoughts. Some people use sldnsmasq to populate ipsets based on dnsnames to figure out which IP addresses are used by, say YouTube, and then dscp mark them to their own desire. Others use iptables rules to detect bulk flows by their accumulated  transfervolume and then dscp mark them. The common thread here is that these techniques fo not work with the IFB way of ingress shaping, since the IFB runs before iptables/dnsmadq/ipset actually has seen the packets and hence they carry their original useless DSCP marks. If your router does not use wifi, you can instantiate the ingress Shaper on the egress side of the interface from the CPU to the lan side, or you can use a veth pair to route ingress traffic into the lan bridge and then instantiate the ingress Shaper on the egress side of that veth...

Best Regards
        Sebastian

P.S.: As far as I can tell IPv6 end hosts will cycle through new addresses, but typically should only use a few concurrently. It would be quite interesting to figure out whether the Xbox updates truly use multiple IP addresses in the first place or whether this is a thundering herd problem caused by synchronized updates by multiple hosts, no?

On 18 August 2020 06:15:55 CEST, Jonathan Morton <chromatix99@gmail.com> wrote:
>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
>_______________________________________________
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 4839 bytes --]