ASSIA court case forces Openreach to turn off DLM

[#1]

Quote from: purleigh

While that statement is a fact about how TCP/IP works,  it is not true in relation to the flow of packets from your exchange to your modem, but is true when considered between your router and the ISP's equipment.  If data arrives at your exchange at a rate that is faster than can be sent on to your modem, the excess packets will be dropped, regardless of whether it is TCP/IP or not, and therefore the exchange takes no part in TCP/IP flow control. Hence the need to minimise these dropped packets, which is currently implemented by restricting the speed at a TCP/IP aware network node, by traffic managing all the incoming packets into a prioritized stream that fits within the known speed profile of your exchange to modem connection.

The only TCP/IP aware network nodes, ISPs using layer 7 devices such as Plusnet's Procera kit to police traffic excepted, in a transfer are the two devices at the edges, the client and the server. The ISP LNS couldn't care less what the traffic is, it happily drops excess regardless and leaves TCP congestion control to do its thing when it sees traffic being dropped - there is no need to do anything else.
As mentioned though ISPs are required to reflect BT Wholesale's link rate in their own LNS profiles to ensure they do not send too much traffic over the BT Wholesale network.
Without these rate limits in place traffic would end up buffering at the DSLAM which is obviously pretty undesirable when ISPs are paying BT Wholesale for traffic in between them and said DSLAM.

[#2]

Quote from: purleigh

Quote from: chrcoluk matter of opinion I guess No it isn't - you are wrong ! Quote from: chrcoluk The only way someone is going to be getting inbound packets too high is either a DDOS attack or malfunctioning software No, that's not right, additional incoming data such as DDOS, would be routed to your connection via your ISP, and therefore would be included in the traffic management, so the total data sent to your BT exchange should still be limited to the "Current Line Speed". Quote from: chrcoluk TCP self regulates and starts slow then works its way up. While that statement is a fact about how TCP/IP works,  it is not true in relation to the flow of packets from your exchange to your modem, but is true when considered between your router and the ISP's equipment.  If data arrives at your exchange at a rate that is faster than can be sent on to your modem, the excess packets will be dropped, regardless of whether it is TCP/IP or not, and therefore the exchange takes no part in TCP/IP flow control. Hence the need to minimise these dropped packets, which is currently implemented by restricting the speed at a TCP/IP aware network node, by traffic managing all the incoming packets into a prioritized stream that fits within the known speed profile of your exchange to modem connection.

you contradict yourself, you acknowledge tcp is self regulating.
So why would packets arrive faster than the modem can handle?
The profile is useful for plusnet mainly for their traffic management as they use it to determine what a line can handle, the reasons you stated has just been rubbish spread by BT for a decade or so.
Various isp's dont use ip profiles at all.  Just because BT does it it doesnt mean all hell breaks loose if it isnt there.
As i said the only reason why traffic would flood a connection is a DDOS or malfunctioning software, software that works properly will not be pushing high amounts of excessive traffic down a pipe. If TCP detects dropped packets it will slow down automatically.

[#3]

Quote from: Melancholie

Quote from: purleigh While that statement is a fact about how TCP/IP works,  it is not true in relation to the flow of packets from your exchange to your modem, but is true when considered between your router and the ISP's equipment.  If data arrives at your exchange at a rate that is faster than can be sent on to your modem, the excess packets will be dropped, regardless of whether it is TCP/IP or not, and therefore the exchange takes no part in TCP/IP flow control. Hence the need to minimise these dropped packets, which is currently implemented by restricting the speed at a TCP/IP aware network node, by traffic managing all the incoming packets into a prioritized stream that fits within the known speed profile of your exchange to modem connection. The only TCP/IP aware network nodes, ISPs using layer 7 devices such as Plusnet's Procera kit to police traffic excepted, in a transfer are the two devices at the edges, the client and the server. The ISP LNS couldn't care less what the traffic is, it happily drops excess regardless and leaves TCP congestion control to do its thing when it sees traffic being dropped - there is no need to do anything else. As mentioned though ISPs are required to reflect BT Wholesale's link rate in their own LNS profiles to ensure they do not send too much traffic over the BT Wholesale network. Without these rate limits in place traffic would end up buffering at the DSLAM which is obviously pretty undesirable when ISPs are paying BT Wholesale for traffic in between them and said DSLAM.

I acknowledge it been useful as a form of buffer control.

[#4]

Quote from: Anotherone

@petecove44 Unluckily you just have a [Censored] line and DLM has given you the [Censored] profile to go with it, simples, unfortunately.

Fair play. It was a perfectly good line until that screenshot I posted. Never mind it's all history now anyway

[#5]

@chrcoluk
I think you are overlooking the situation where there are multiple streams running at the same time - yes each individual stream will self regulate, but there is nothing that TCP can do to control the relative speeds of each stream so that they only add up to the total capability of the line. If one stream pauses for a short time (say a VoIP call), something like a download will ramp up to take up the slack. When VoIP tries to start again it will find little speed available and it's TCP will not ramp up.
Edit: See following post - VoIP was not a good example but the principle is correct - and it has raised another relevant point.

[#6]

... and using VoIP as an example, that uses UDP instead of TCP, and UDP does not have the same flow control that TCP has.

[#7]

... and the same as VoIP when streaming video. No flow control, and visible/audible artifacts when something goes wrong.
And lets be honest here ... BT's target is almost certainly focussed on giving a broadcast-like quality experience for TV. That target implicitly sets targets for both DLM and QoS.

[#8]

Unsure if this is to do with the supposed 'switching off' of DLM on FTTC:
My (Fritz!Box) router reports Max. DSLAM throughput and Min DSLAM Throughput amongst other DSL stats and used to show 'banded' ranges matching the standard FTTC profile names (typically 37M-74M down and 10M-20M up for my connection) but I'm now seeing Max DSLAM Throughput of 80000 down / 20000 up and Min. DSALM Throughput of 128 down and 128 up.

[#9]

DLM is not turned off. For clarity here's the key snippet from the quote you've probably already seen from BT:
[quote=http://www.ispreview.co.uk/index.php/2014/11/uk-court-appeal-rules-bt-fttc-broadband-infringes-assia-patents.html]Although BT was disappointed with the ruling, we have made minor changes to our programming which means these two decisions have no material effect on the operation or performance of our networks