Will 50mb get STM'd when 100mb gets rolled out?

[sniper007]

I've not seen any definitive answer on this as of yet. What is the timeline for 100mb roll out? I know it is to be a new tier. Will they leave 50mb alone?

[Sephiroth]

I hope so. I'm upgrading to 50 meg shortly and I'd like not to be swamped into unusability! :p:

[Chrysalis]

my guess is they dont need a STM on the downstream on docsis3 however upstream should have a STM.

[Ignitionnet]

It may get introduced to motivate people into upgrading to 100Mbit.

IMHO all the services should have some kind of controls on them, not STM but bitcaps or shaping, but I'm fascist like that I guess ;)

[sniper007]

\to be honest I really don't "abuse" my connection, I just got sick of being shaped when going past 1.5gb or so during peak times. Atleast allow people to do it once a week maybe?

[SideWeaver]

Yeah, the upload should be STM'ed for sure. I know once the upstream is upgraded permanently I would love to stream stuff which requires a good upload limit.

[Ignitionnet]

\to be honest I really don't "abuse" my connection, I just got sick of being shaped when going past 1.5gb or so during peak times. Atleast allow people to do it once a week maybe?

Or you could just pay more for a higher peak cap?

[Chrysalis]

ignition to be fair I think the download peak cap is poor, I am on 20mbit the highest STM package and I can hit it very quickly, whilst to hit the upload cap (very generous) it takes hours.

Considering supposedbly most of the congestion is on upload why is the upload STM much more generous?

[Ignitionnet]

Upload is not the main issue on the non-XXL packages, download is.

If the package is considered inappropriate for needs there is always the potential to upgrade to XXL or XL if on L.

Contrary to popular belief Virgin do have some idea how their networks are loaded - upstream wasn't much of an issue until XXL and the overlay build and separating people on each network who are on the same tiers would be amazingly confusing to people ;)

A table with 'Overlay' and 'Non-Overlay' sections would be a nightmare.

[Chrysalis]

ok so what did you mean before when you said the bulk of congestion on VM's network is upstream?

also what are your thoughts on this? upstream or downstream, it is legacy.

http://www.cableforum.co.uk/board/12/33669685-terrible-performance-leicester-le3.html

[Ignitionnet]

ok so what did you mean before when you said the bulk of congestion on VM's network is upstream?

also what are your thoughts on this? upstream or downstream, it is legacy.

http://www.cableforum.co.uk/board/12/33669685-terrible-performance-leicester-le3.html

Link me to where I discussed it so that I can see it in context.

Answering your second question probably upstream - slow upstream, high latency, packet loss.

Most congestion remains downstream due to network construction, vast majority of areas are virtually symmetrical in capacity upstream and downstream, overlay and QPSK upstream areas being an obvious exception. A 400 modem MC28 1-4 service group has 95kbps downstream and ~90kbps upstream per modem which works fine on services with 20:1 or worse ratio.

[Chrysalis]

sure I will look for it as I remember you telling me this in public on the forum on this site, it was something along the lines of downstream congestion is almost non existant and most of congestion on VM's network is upstream. Of course I may have misunderstood you so will look for the thread.

How much of VM's legacy network uses QPSK? more people who post stats seem to be on it than QAM16.

I know my legacy port had/has 2 downstream and 4 upstream, If I understand right if it was 1 QAM256 down and 4 QAM16 up then that would be almost symmetrical but still not, instead however it is 2 256 QAM down and 4 QPSK up. It had downstream congestion as you diagnosed for me but it also had upstream congestion as you also diagnosed for me. I dont know if its changed now, but thats how it was configured when I was on it.

Thanks for confirming that particular legacy port has upstream congestion, so that shows VM have done something wrong there, whether its been too generous on upload STM or under investment on capacity, or maybe they consider it to have nothing wrong and have no problem selling service with that kind of quality. That was my point on the upload STM. I hope you can understand my comments on VM and STM etc. are based on my own customer experience and of people I talk to who are also on VM. I am the only person I know in my city who has the quality of service I have now, everyone else I know who lives here online or personally is suffering badly. Its a big city with a lot of people and high VM takeup, not insignificant.

[Ignitionnet]

How much of VM's legacy network uses QPSK?

Not much.

more people who post stats seem to be on it than QAM16.

At a guess because people whose service is running fine don't post stats. With advanced spectrum management issues on network tend to cause a drop to QPSK modulation.

I know my legacy port had/has 2 downstream and 4 upstream, If I understand right if it was 1 QAM256 down and 4 QAM16 up then that would be almost symmetrical but still not, instead however it is 2 256 QAM down and 4 QPSK up. It had downstream congestion as you diagnosed for me but it also had upstream congestion as you also diagnosed for me. I dont know if its changed now, but thats how it was configured when I was on it.

Again this might be your experience but isn't the norm. Dual DOCSIS downstreams are the exception rather than the rule and are used specifically to relieve downstream congestion.

Thanks for confirming that particular legacy port has upstream congestion, so that shows VM have done something wrong there, whether its been too generous on upload STM or under investment on capacity, or maybe they consider it to have nothing wrong and have no problem selling service with that kind of quality. That was my point on the upload STM. I hope you can understand my comments on VM and STM etc. are based on my own customer experience and of people I talk to who are also on VM. I am the only person I know in my city who has the quality of service I have now, everyone else I know who lives here online or personally is suffering badly. Its a big city with a lot of people and high VM takeup, not insignificant.

No idea of Leicester's size or takeup however I would disagree with you that you are the only person in Leicester with a half-decent service. On the LE3 overbuild there may be issues however these are not normal operation for the networks. Your bit of Leicester is also nice and student heavy which equals abnormal levels of upstream utilisation.

One area's experience isn't typical. I'm sure you know better than to extrapolate a small area and a few forum reports from people with issues to all nearly 13 million homes on the VM network.

16QAM is the standard build and has been for a while. 1-4 down-up ports is the standard build and has been for a while, some areas remain using 1-3 on earlier model line cards.

There is no pressing need to make upstream STM more severe, there wasn't previously and isn't now. Increased reports of upstream congestion might happen due to ASM along with usual levels of P2P and other activity however, due to the increased usage of streaming services, newsgroups and download services, the ratio of upstream usage is actually dropping relative to downstream.

[Chrysalis]

:) I never said I was the only one, obviously at the very minimum others on my port will be getting the same level of service.

However I strongle disagree with your comments on a pressing need to manage upload use, it doesnt matter if its 1 area or 100 areas if you a company who values the service you provide. Also you keep discounting large city areas which have congestion as insignificant, if we look at customer count in terms of numbers rather than number of areas (since it sprobably low takeup areas with best performance) then the % is I expect larger than you think, also considering that various congested areas are officially deemed within normal operating parameters by VM.

Also we both know as far as my own particular area is concerned the students are not to blame for this one (which I did let you know during the summer) as the congestion remained and barely changed when they went home. The only 2 times I had significant change in performance was (a) when moved from legacy to overlay and (b) when that work was done a couple of weeks back. whether or not students are home or not seems to be making little difference, also not all of us in leics are living in student areas, the city does have non students as well. Then of course we have all the other big takeup VM areas with similiar issues, bristol, preston, machester.

[Ignitionnet]

There are pockets with issues all over, just as there are on every cable network. Doesn't justify changing policies to detriment every user, including the overwhelming majority whose service is running just fine.

My area, with its' QPSK upstreams, had a touch of downstream congestion issues before 50M went live. Even with only 3 x QPSK upstreams, 38Mbps downstream 13.5Mbps upstream, it still saw no upstream congestion. Does this mean upstream STM isn't generous enough or downstream too generous?

[Chrysalis]

I am giving up for now on looking for your psot :) will just accept what you saying now, but if I come across it will let you know.

What you saying with the ACK manipulation stuff concerns me tho, isps really shouldnt be artifically messing with ACKS, and there are certian apps that require nagle alogrithm off to work optimally, the most famous one I can think of is world of warcraft which when delayed acks are disabled the latency reduces by at least half.

Securecrt and putty both forcefully disable delayed acks as that makes ssh jittery (every 2 packets getting ack). Delayed acks are great for file throughout but when sending lots of small packets that dont fill a tcp window then delayed acks hinder things.

[jb66]

What concerns me is are they going to call it xxxl?

[pip08456]

What concerns me is are they going to call it xxxl?

Well seeing as we had bare female arses for 50Mb how about plain and simple XXX for 100Mb?

[Ignitionnet]

I am giving up for now on looking for your psot :) will just accept what you saying now, but if I come across it will let you know.

What you saying with the ACK manipulation stuff concerns me tho, isps really shouldnt be artifically messing with ACKS, and there are certian apps that require nagle alogrithm off to work optimally, the most famous one I can think of is world of warcraft which when delayed acks are disabled the latency reduces by at least half.

Securecrt and putty both forcefully disable delayed acks as that makes ssh jittery (every 2 packets getting ack). Delayed acks are great for file throughout but when sending lots of small packets that dont fill a tcp window then delayed acks hinder things.

It doesn't delay anything, it's just making better use of the data grants. Instead of going through a request -> grant -> transmit cycle for each and every ACK it makes a request and when it gets a data grant sends a single cumulative ACK for the flow instead of a going through a series of r-g-t cycles for each and every ACK. No ACKs are artificially delayed they are just packaged together and synchronised with DOCSIS.

In addition to the TAS / TCP Ack Suppression there's also Concatenation which can run side by side - with this technology multiple Ethernet PDUs are packaged together so that instead of a series of requests for each Ethernet PDU they are packaged together - again synchronising to DOCSIS to make more efficient use of the bandwidth available and work around DOCSIS limitations.

[Chrysalis]

is this in place now? it seems to not be negatively affecting ssh so I guess they made it kick in dependent on certian traffic conditions.

[Ignitionnet]

is this in place now? it seems to not be negatively affecting ssh so I guess they made it kick in dependent on certian traffic conditions.

Both have been active for ages. TAS was switched off for a while due to firmware issues on the 50Mbit modem but is coming back now that the firmware is fixed.

See what I said earlier - the whole point of TAS and concatenation is to give TCP a better fit to DOCSIS - there is no additional delay induced by them.