Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PhilT]

I'm not convinced at all that "it may perhaps have been more sensible to round up the bRAS profile rather than the current system of rounding down" as per http://www.kitz.co.uk/adsl/maxdsl2.htm

My understanding of ATM is limited but I know that BT require your modem to limit the data rate upstream so that it doesn't exceed the link speed (hence a router may be configured with an upstream of 288 then update itself to 448 or 832 or whatever when the connection is made).

ATM switches have little or no buffer capacity and the concept AIUI is to dimension the ATM circuit end to end according to its weakest link in order to avoid loss of cells. If you were to round up a BRAS profile and push 2272 worth of data at an 1792 link the loss of a few ATM cells would case quite a lot of packet loss - the sort of thing Entanet's ALT is designed to avoid. There are papers that show the steep drop in performance as a TCP/IP over ATM link approaches capacity and I think it is this that BT are seeking to avoid with the current system.

The size of the increments and the frequency of changes is a logistical question about how much traffic the DSLAMs can generate from changes and how much processing power you need to manage it. Apparently more than 25% of lines change at least once a day.

So I don't think it would be a good idea to round up the BRAS / IP profile on an ATM system, but I'm open to convincing that it doesn't matter 

Phil

[kitz]

Hiyas Phil

Thanks for taking the time to post..  sorry for the delay but Ive not been around for the past couple of weeks.

You make some very valid points and I fully appreciate where you are coming from.
I still have a lot of catching up to do, so this is going to be a "quickish" reply.

Firstly that page was written soon after Max came out and there is an update due - Ive been busy over the past couple of months and actually have (one of many) half written pages for an update on the IP profile.  Ive just checked - eke I actually coded a new IPprofile tool 25 April 2007, 21:38:56. 
Hangs head in shame that I deferred it (re the new profiles and then again re new Adaptive logic).
But I feel the IP profile needs a dedicated page of its own.

Okies back on topic.

When that was written I was concerned that someone who was syning at say 5088 kbps would be allocated a profile of 4000, which is quite a lot below the sync speed and therefore the user wasnt perhaps able to get as much out of his line that he could or should be able to.

Also since then Ive been led to believe that the bRAS profile and the IP profile although very much related arent actually quite the same thing .  The IP profile makes an allowance for overheads and therefore the limit applied on the RAS is actually a bit higher than the IP profile to compensate for this.

I fully understand what you are saying about problems occuring when nearing capacity and something I harped on about a few years ago when PN were nearing capacity on their centrals a few years back pre ellacoya days.

------


A couple of things I find interesting though and to play devils advocate at which point does the VP become congested and where is the (downstream) traffic going to be bottle-necking?

VP congestion is something that is dealt with all over the country every day - its seldom that anyone gets full pelt during peak times and or 24/7 and the BT systems are well used to coping with more data being pushed at the VP than what is actually available.  Ive also suspected for many years that BT also have some form of basic traffic prioritisation in place when congestion occurs.
Not to the extent of what ellacoyas are capable of - but there is certainly "something" in place.  Even way back in May 2003 when there were 30+ users screaming at BT from this exchange that speeds were very poor (prior to this exchange contention was basically unheard of)..  but not one of those users was seeing a problem with latency.  Same again in 2004/2005..  and typical when the new 1Mb and yet again when 2Mb came out...  slower speeds but no decreased latency.

Another common argument is that LLU seems to cope ok without IP profiles.


Btw something else you may (or may not:D ) be interested in.

A couple of months ago I did some testing with one of the guys from PN - I questioned the way they were putting a lower "data rate" profile on the customers account than the bRAS.  PNs argument was that if they set it higher then the EU would see packet loss.

TBH I dont really want to log into PUG now (not been there for many weeks and theyrd likely be too much catching up to do)... but IIRC the results went something along the lines of.

7000 (PN data rate) profile - max speeds in the region of 6700/6800 kbps.
7500 (PN data rate) profile - max speed 7060 + kbps
8000 (PN data rate) profile - max speeds of 7060 kbps + (best speed was actually acheived on the 8000 profile although I realise that this was likely co-incidental since there should be no benefit of a 8000 profile over a 7500 one).  irrc DUMeter was flatlining (inc overheads) at around 7.4 Mbps on both of the last 2 profiles.

I think that put paid to their assertion that lines would perform worse with a 8000 profile rather than one with a 7000 profile... although I fully realise that I would still be limited by the profile set at the RAS.


----------------

Anyways Ive rambled on a lot more than I intended to do... 
I Will remove that statement (the table will also be going from that page and moved to the other) when I get around to completing this one. - Preview of IP profile thingy page - showing that it was under review - will try get it finished asap.

Sorry if the above came out a ramble but it was a type straight as it came out of my head thing.

Thanks once again for bringing it to my attention...   as always your comments/suggestions/contributions are always respected and most welcome.

[kitz]

Done - New page uploaded http://www.kitz.co.uk/adsl/IPprofile.htm

[PhilT]

I think the LLU argument is irrelevant as they aren't using ATM so the DSLAM is IP backhaul and all the traffic can be jumbled up together. ATM systems are dimensioned for individual separate virtual circuits which is where the profile comes in.

When they call it an IP Profile of 2000 it is the 2272 ATM rate of a 2M service so I agree on the overheads.

I don't know how the backhaul manages the contention issue either, the connection onto a DSLAM is I think smaller than the sum of the card capacity to it has to do contention on its backplane. If it looses ATM cells the books say it all goes badly wrong, so this suggests that the BRAS profiles on a congested VP all get scaled down by a factor to keep the system in balance ?

Phil