Hi Mikael,
> On Apr 2, 2019, at 15:04, Mikael Abrahamsson <swm...@swm.pp.se> wrote:
>
> On Tue, 2 Apr 2019, Sebastian Moeller wrote:
>
>> See above how Deutsche Telekom deals with that issue, at least in the
>> German market.
>
> I've read rumours about some ISPs implementing interaction with the VDSL
> DSLAM where there is an estimation of the current link-speed for each
> individual customer and then it tries to set the BNG egress shaper
> appropriately.
I believe this is what Deutsche Telekom actually does already.
>
> I am very happy about my FTTH solution I have now since from what I can see
> the L2 network is almost never a limiting factor (much better than my DOCSIS
> connection) so my bidirectional SQM with CAKE seems to work very well.
I envy you ;) that said, I have little issue with my VDSL2 link, but at
50/10 it is hardly pushing the limit. DOCSIS with its often huge segments is a
mixed bag, I have head od segments with 1000 customers and no issue even
saturating a DOCSIS 3.1 1000/50 plan, and also people with severe issues with
more modes 100/20 plans.
>
> Still, the HGW can never solve these problems properly,
Assuming fixed bandwidth, it can do a pretty good approximation of
properly though ;)
> the egress shaping in the BNG needs to do a proper job.
I agree, but then my wishlist includes flow-queueing and then reality
intervenes, and I keep having to do this on my side as BNGs do not offer fq for
customer bandwidth shaping/policing, and might never do.
> From what I have been told, there has been improvements here in the past few
> years.
I agree, when I started with Deutsche Telekom latency under saturating
load spikes (in ICMP probes) were above 1000ms in 2015, but now with the
Juniper BNG shaper solution I saw around 300ms (I switched ISP, but the cap is
still around 300ms). IMHO this is much better, but also far away from good
enough, so I keep shaping on my end to keep latency acceptable (with a 50/10
link saturating loads are common enough to justify the time spent for
configuring the home ingress shaper IMHO).
>
> What I am more worried about is the egress shaping from the HGW.
If you ask me that is going to come, all shared media links (docsis,
G-PON, ...) already need this to keep customer modems from shouting over each
other.
> I talked to several vendors at BBF and they talked about ingress policing
> being commonly used on the BNG. This means no ingress shaping at all (just
> packet drops if they exceed the configured rate).
I wonder how that rhymes with the 300-1000ms added latency I see under
load, assuming the BNG-limiter to be the bottleneck.
> I don't know about buffering on the HGW though and how the policed rate is
> set compared to the L2 rate the HGW can send via.
Typical DSL modem-routers and DOCSIS modems (presumably < 3.1) often
show pretty manly buffering (that is to say probably a bit too much with too
little brains attached ;) ). I note that the L4S-project already identified
CPEs as the next target to get upstream queueing tackled, I see no chance for
doing that effectively without getting the ISPs on board. I have no idea how
well the heavy cable labs involvement will sit with the old telco incumbents
and whether any non-ITU standard will fly. But let's see...
Best Regards
Sebastian
>
> --
> Mikael Abrahamsson email: swm...@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
