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
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 David_W (Wed 23-Jan-13 02:33:37)