IP Profile - 88.2% method

[#1]

I have seen some discussion on the BT broadband forums about different methods how the IP Profile is updated.
It talks about the "Adaptive method" which I believe plus net use now, and also a new method called the "88.2% method"
Can we request a change to the 88.2% method?
Link to discussion on IP Profile on BT Broadband forum:
http://community.bt.com/t5/BB-Speed-Connection-Issues/IP-Profile-change-methods/td-p/211701

[#2]

Good find. I think this might in some way explain my "stuck" profile and maybe some of the others. I thought the BT speedtest IP profile was an unusual number, but it seems it is 88.2% of the sync value. Problem is the plusnet end of it isn't.
According to the post, its only going to apply to 21CN exchanges.

[#3]

This method is essentially an admission that the whole concept is flawed.
On LLU services that are not subject to any sort of profiling/throttling a good "rule of thumb" has been that downloads will at best be around 85% of sync speed.
In reality other protocols come into play and 88.2% is probably almost irrelevant as a limit.

[#4]

Unfortunately I wish I was on the new method. My connection speed is 1,696kbps but I am stuck on a 500kbps IP Profile!
My speed isn't great anyway, but dropping from the usual 1.25Mb to 500kbps is a nightmare, especially as I am working from home today. 😞
Not happy.

[#5]

Hi mbailey3,
Unfortunately BT show your profile at 500k as of the 19th, so it might be worth resyncing the connection around lunchtime to see if that can be improved? I'll up your profile on our side and see if that makes any difference but I'm not sure it will with the BT side as it is.
Might be worth trying a BT speed test to see what that has your profile as?

[#6]

I've moved my modem this morning and plugged it into the master socket. I have run a couple of BT speedtests this morning and it shows the sync rate as 1600, ip profile as 500 and the speed as 460.
I tried a resync 1hr ago and it syned at 1,696kbps again, but no update on the IP Profile.
I will try another resync in 30 minutes and see if that helps.
adie:quote

[#7]

Quote from: HPsauce

This method is essentially an admission that the whole concept is flawed. On LLU services that are not subject to any sort of profiling/throttling a good "rule of thumb" has been that downloads will at best be around 85% of sync speed. In reality other protocols come into play and 88.2% is probably almost irrelevant as a limit.

Speed has to be controlled somewhere. It's no good a server sending data at 10mbps if the users connection is only 2mbps. So how does the LLU equipment control the speed?

[#8]

Well my PC sends data at 1Gbps to a switch that forwards it at 100mbps to a router that sends it at about 1300kbps (ADSL2+ upload speed)....
Not an IP Profile in sight there, and that's just sending an email for example.
TCP/IP and all that, buffers, packets, acknowledgements/retries etc etc. 

[#9]

So why does BT use profiles and not rely on the TCP/IP protocol? Is it not that they are moving this down to the ISP? As LLU are the ISP there is no need to make public the profile as they are completely in control.

[#10]

Quote from: itsme

So why does BT use profiles

No idea myself. Maybe they thought it was necessary to manage systems when rADSL was first designed? And quite possibly it was.
It seems (to my uneducated eye) to be an unneccesary complication now that other elements of the technology have moved on.
And that's my personal interpretation of 88.2%; it's still there in case they need to re-enable it, but not actually doing anything in practice. 

[#11]

Do the TCP/IP flow control protocols work with an ATM link in the path?

[#12]

Quote from: mbailey3

Can we request a change to the 88.2% method?

Sounds to me like the bRAS quantization we have been seeing on some 21CN customers.
Jojo

[#13]

Well any method would be fine with me as my profile has refused to update for weeks!

[#14]

Quote from: spraxyt

Do the TCP/IP flow control protocols work with an ATM link in the path?

As I understand it Yes and No. By design TCP doesn't  positively acknowledge each packet before the next is sent otherwise the performance on high latency links would be appalling. I believe flow control works by the TCP receiver sending a "stop" message (technically an ACK with 0  in the buffersize) if /when its receive buffer fills. Each unit that talks TCP does this to the prior link in the TCP connection - that's why its called a store and forward protocol and where transmission delays, latency and traffic prioritization creep in. ATM is a lower level protocol and was designed to handle packetized voice when such delays and latency are far less acceptable. It doesn't buffer traffic to anything like the same extent and any significant flow control which occurs is regarded as an error condition on the link.
The two TCP  "ends" for a 20CN ADSL network (21CN is probably different and I don't know how )  are (as I understand it) your router and the ISP's kit.
BT's problem is that the  link between the ISP and your router is not uniform and the bottleneck is the last link between the exchange and you. Your router can probably empty its receive buffer ( to your PC) as fast as the ADSL link will go - so it never needs to send out the TCP "stop". So something else has to control the flow of traffic into the ISP's end of the link and constrain it to something like the speed of the ADSL section.
Without a BRAS profile or something similar then when your machine said "ready" the ISP would be capable of dumping stuff into BT's network at the speed of their pipe, but BT would be unable to forward it to your router at anything like the same speed. The only available flow control would be when the BT network threw away packets and your machine asked for retransmission - not a good process when the difference in speed between your ADSL link and the ISP's pipe could be 1:1000.

[#15]

So in essence, BT don't want to fork out big buffers.... I can see why.
I'm with others here, I have and continue to come across many links that are constrained merely by the slowest transmission link, rather than an artificial throttle being placed on it.  If the cause is purely that BT don't want to pay for buffering, then so be it.
I do think they need to bring sales/marketing and reality a bit closer together though.  If real life says you'll only get 88.2% of your max sync speed, then Sales/Marketing should never ever sell it as 24Mbps.  As by their own admission, you'll only get 88.2% of that.
Fortunately PN mostly keep clear of quoting max speeds (Fibre products being the exception, and I get why that's done as it is too, to differentiate the product).
Just my 2p.