You'll have to wean yourself off that copper nomenclature. No 'sync' as such with FTTP....😎😀

Could not think of an alternate word ... The hub tells me it is a 1000 FTTX link, will get exact words later. That is way higher than the 300 Mbps restriction on my service.

That's the Ethernet link speed between your hub and the ONT. The reason it's 1000 and not 300 is because the speed of Ethernet is standardised and there's no such thing as a 300mb/s Ethernet link-speed. The next speed down is "fast ethernet" (100mb/s) which is slower than your 300mb/s service so a link-speed of at least 1000mb/s is required in order to deliver a 300mb/s service.

And FWIW, the link speed over the fibre itself is fixed: it's 2.4Gbps in the downstream direction, and 1.2Gbps in the upstream direction. One link can be shared between up to 32 properties.

When you buy a particular speed of service, say "330/50", then packets are delayed and/or dropped to ensure that on average you don't exceed that level of traffic.

In reply to a post by candlerb:

When you buy a particular speed of service, say "330/50", then packets are delayed and/or dropped to ensure that on average you don't exceed that level of traffic.

I would hope sincerely that they don't drop packets to achieve an average throughput. I can't think of anything more stupid.

In reply to a post by jabuzzard:

I would hope sincerely that they don't drop packets to achieve an average throughput. I can't think of anything more stupid.

Packets have to be dropped in order to signal to TCP to slow down(*).

Usually the policer has some sort of "leaky bucket" algorithm, which allows you to burst and then starts dropping packets until your average throughput falls to the right level.

The alternative is to put packets in queues and pull them out at a limited rate - but that gives rise to buffer bloat, i.e. large latency. If the sender keeps sending above the permitted rate then the queue is going to fill up anyway, at which point you're back to dropping packets.

An intermediate approach is Random Early Drop - where a small amount of packet loss is introduced before the queue is full. This gives an early hint to TCP to start slowing down.

(*) OK, there's Explicit Congestion Notification, but that's not yet fully deployed AFAIK.