BRAS profile changing daily

Hello everyone. Hope you are all enjoying the snow...! Having visited http://www.beusergroup.co.uk/ and checking my BRAS profile over the last month or so I notice that my download speed varies between 45 and 59 Mbps. My upload profile is consistently 20 Mbps. I am on Infinity 2 by the way. I am approximately 350m from the cabinet. The thing is my upload speed is only 4 - 5 Mbps so I can't understand why the upload profile stays at 20 Mbps but the download fluctuates on such a regular basis. Can anyonen shed any light? Thanks

The upload might be capable of say 25 or 30M but your service is only "up to 20", hence it is never challenged.

The downstream is obviously fluctuating more, due to interference factors perhaps. As it's "up to 80" you see the number change.

What protocols give you 4-5 Mbits/s upload ?

yarwell - thanks for the response. I get the upload speed from speedtest.net the bt speedtester and another one that a lot of folks in here say is accurate for providing upload speeds. No idea why it is so low given that my folks across the road get nearly 9Mbps on the Infinity 1 package. Not sure what you mean by protocols in this instance?! Sorry if being a bit dim.

apparently the upload profile is always 20mbit even when sync is lower.

The downstream profile is needed to limit traffic offered to the end point to that which it is capable of accepting. Without limiting traffic in that way, congestion would have a seriously detrimental effect, which is why BT Wholesale implement a downstream IP profile.

All the ISP has to do for upstream traffic is accept all the traffic offered. As all ADSL and VDSL products are asymmetric, but the links the ISPs purchase are symmetric, this shouldn't be a problem for any ISP.


If SIN498 is followed, the BRAS gets the FTTC sync speeds in the PPPoE negotiation via the tags described TR-101. This will be handed on to the ISP's RADIUS servers. For those ISPs using DHCP (Sky), the same information is carried over DHCP Option 82.

Unfortunately, TR-101 tags are stripped out by the DSLAM on the FTTC customer side (as documented in SIN 498 and I've confirmed by packet sniffing my connection). I regard this as a shame, because it prevents discovery of sync speeds on every negotiation and adjusting your traffic shaping to suit. I guess BT Openreach decided on this approach rather than breaking PPPoE implementations that break the PPPoE RFC by malfunctioning when presented with unexpected tags.

In reply to a post by David_W:

The downstream profile is needed to limit traffic offered to the end point to that which it is capable of accepting. Without limiting traffic in that way, congestion would have a seriously detrimental effect, which is why BT Wholesale implement a downstream IP profile.

I don't believe that for a minute. Doesn't make sense! Which end point? You talking about congestion at the user's network end?

In reply to a post by XRaySpeX:

In reply to a post by David_W:

The downstream profile is needed to limit traffic offered to the end point to that which it is capable of accepting. Without limiting traffic in that way, congestion would have a seriously detrimental effect, which is why BT Wholesale implement a downstream IP profile.

I don't believe that for a minute. Doesn't make sense! Which end point? You talking about congestion at the user's network end?

Any end point - though in this case, a DSL customer via the downstream. See SIN 498 section 2.1.6:

The CP is expected to shape the downstream traffic to match the actual VDSL2 line rate in order to avoid excessive traffic loss.

Customer Party (CP) in that quote is BT Openworld's customer, which may be BT Wholesale for ISPs using BT Wholesale backhaul.

If you try to push more data down a wide network connection (such as a backhaul network) than a narrower hop downstream (such as a DSL end user's downstream), various undesired effects occur, with packets arriving out of order and randomly being lost. It's better for things to degrade in a predictable way at link saturation by limiting the amount of traffic being launched towards the link in question.

You can see similar effects at upstream link saturation - though that's entirely up to the end user, also the majority of link saturation on consumer broadband is in the downstream direction. This end user traffic shapes and prioritises his upstream traffic before offering it to the BT Openreach FTTC modem.


Edit to add: the undesired effects in question apply particularly to TCP. Once packets start to arrive out of order, you can get wanted packets arriving so far beyond a missing packet as to be outside the receive window, so those packets, too, are effectively lost. Meanwhile, (selective) acknowledgements are causing retransmission of some of the missing packets, which may fail to make it through a second or subsequent time. At this point, the throughput of the TCP socket crashes to the floor, potentially to recover, surge beyond the link capacity and crash again.

It's better to shape traffic to below the capacity of the widest link. TCP adjusts fairly quickly to the available bandwidth. UDP is more difficult - though UDP traffic is not guaranteed delivery, which means it should either be time critical (get through now or don't get through) or have backoff and retransmission implemented at a higher protocol level. UDP is used for most DNS queries as the cost of setting up a TCP socket for most queries is disproportionate to small size of the payload. UDP is also used to transport some types of VPNs - the encapsulated traffic will use a protocol with appropriate backoff and retransmission properties and the last thing you want is TCP-type backoff and retransmission being applied twice (to TCP) or inappropriately (to UDP).

Though I have no inside knowledge, I'd expect the shaping of DSL downstream data to prioritise UDP up to a reasonable proportion of the link bandwidth, with TCP adjusting to the available bandwidth.

Edited by deleted (Wed 23-Jan-13 02:33:37)

Obviously in context, I was talking about & quoting this case - Downstream.

In reply to a post by David_W:

The CP is expected to shape the downstream traffic to match the actual VDSL2 line rate in order to avoid excessive traffic loss.

It's getting late now but I don't see "traffic loss" synonymous with "congestion".

In reply to a post by XRaySpeX:

Obviously in context, I was talking about & quoting this case - Downstream.

In reply to a post by David_W:

The CP is expected to shape the downstream traffic to match the actual VDSL2 line rate in order to avoid excessive traffic loss.

It's getting late now but I don't see "traffic loss" synonymous with "congestion".

The explanation is in the 'Edit to add' paragraphs of the post you just replied to. Once a TCP packet is lost or delayed due to congestion, everything arriving from outside the receive window (which, at this point, starts with the first awaited packet) is also lost because it has to be retransmitted by the sender. You can finish up with highly deranged behaviour, where the majority of data which did get through is thrown away as outside the receive window - which is equivalent to massive packet loss.

The scaling window behaviour of TCP adjusts the sending speed according to the rate of acknowledgements, with selective acknowledgements allowing retransmission of missing packets without throwing away usable data that falls inside the receive window. However, this sliding window mechanism, which rate adjusts the sender, cannot be aware of other traffic limiting the available bandwidth - it only discovers about it after the fact when it has to retransmit data. It's therefore better to shape the downstream traffic to avoid this risk of packet loss - rather than each packet taking its chances due to congestion, you shape the overall traffic to the available bandwidth and keep TCP traffic in packet order, allowing TCP's sliding window transmission dynamics to work much better.

Sorry, too technical for me. I do know about RWINs and I doubt it has much to do with IPPs which I believe has more to do with protocol overheads.