In reply to a post by garethr:

I don't think it was the wrong place. They had some massive issues in the area because of the way their network was deployed. Most of the FTTP properties are lucky to get 1Mbit ADSL. It was also easier to trial FTTP in MK as we already have ducting into each house.

So the trial is very much delayed. They started in 2010 and still haven't finished.

Thank you Gareth. You have rather confirmed things.

Bad network, check. Network here was in a bad state thanks to no communication between developers and Openreach so we ran out of e-sides in the wider area and on this cabinet d-sides too. People waited for the best part of a year for a phone line.

Bad ADSL, check. Varies from 300kbps to an unstable 2Mb for a lucky few.

Ducting to individual properties, check.

I am guessing by the tone of your post remaining residents are getting a bit grumpy?

The bigger PON splits aren't a problem by the way. CWDM would actually benefit you however PON can be split between 128 drops and given most will buy 40 or 80Mb it is probably not an issue.

In reply to a post by Chrysalis:

Also packetloss will kill performance if present, the recent BTw capacity issues only highlighted that. There is a big difference between temporary small amount of dropped packets when TCP has to throttle itself, to constant large packetloss from a backhaul supplier, TCP wont handle the latter well in terms of performance. So in terms of network congestion, delayed packets is favourable to dropped packets.

You've actually more or less exactly contradicted yourself in this paragraph. When there is congestion the TCP/IP endpoints should throttle, and the most effective way to signal that is to drop packets not delay them. It makes sense to queue packets very briefly, to smooth out the moment-by-moment variations. But in real systems, especially at the edge, cheap RAM means a tendency to allow queues to grow into hundreds of milliseconds. This is counter-productive.

Packet loss that's independent of throughput is a fault, not a reaction to congestion, and it should be repaired just like any other type of fault.

PC providing you are on an enabled cabinet - vouchers cannot be used to fund cabinets only connection to them

tcp/ip will self regulate when the end to end point is saturated.

it cannot deal with major isp congestion, instead it will just run very badly. Of course I am also reffering to packetloss caused by a fault as well, the point is any intermediate device thats not the endpoint causing packetloss will not be dealt with well.

isp congestion shouldnt be there in the first place, thats the proper way, but if it is there, delayed packets are a lesser evil than dropped packets.

the intermediate routers dont provide feedback to the end point serving the data they just pass on the packets, so the end point receiving the data doesnt know slow throughput is due to congestion.

Edited by Chrysalis (Sun 04-May-14 17:47:50)

In reply to a post by Chrysalis:

it cannot deal with major isp congestion, instead it will just run very badly. Of course I am also reffering to packetloss caused by a fault as well, the point is any intermediate device thats not the endpoint causing packetloss will not be dealt with well.

TCP/IP doesn't care where the bottleneck is. I have no idea where you could have obtained the idea that it does, or even could.

the intermediate routers dont provide feedback to the end point serving the data they just pass on the packets, so the end point receiving the data doesnt know slow throughput is due to congestion.

Actually the "feedback" from routers is mostly in the form of dropped packets. You send packets out, if some of them aren't received then presumably those packets didn't fit, the pipe is smaller than you thought. Exactly how TCP/IP behaves next is up to the implementation, you can read about well known algorithms like Vegas or New Reno for yourself. Every node along the route is capable of dropping a packet, so there is no difficulty with this method of feedback and TCP/IP was conceived from the outset with it in mind.

You are correct that the receiver has no way to distinguish packets dropped due to congestion from packets missing due to errors. In practice hops with significant unrecoverable error rate are unsuitable for TCP/IP and no such links are used intentionally for the Internet. Where a medium makes errors unavoidable (e.g. radio for WiFi) the link-layer protocol must be beefed up to make recovery possible within that hop, so that the IP packet still arrives intact, even if the underlying medium had to retransmit it.

in short I think someone who manages a device on the internet that forwards packets (router) and have knowledge that device is dropping data packets for whatever reason may it be resource saturation or a fault is been irresponsible if they assuming tcp/ip will handle it fine. (not to mention not everything uses tcp).

In reply to a post by Chrysalis:

in short I think someone who manages a device on the internet that forwards packets (router) and have knowledge that device is dropping data packets for whatever reason may it be resource saturation or a fault is been irresponsible if they assuming tcp/ip will handle it fine. (not to mention not everything uses tcp).

Aside from toy implementations (I think somebody made simple TCP/IP work on a Commodore 64 for example) everybody has congestion management algorithms in their TCP/IP implementation to allow them to get reasonably good transfer rates on the Internet.

Maybe that seems contradictory, why would you need congestion management to go fast but not to go slowly like a Commodore 64? To actually get the high transfer rates we need to avoid exceeding the link capacity at the narrowest bottleneck so that the packets we transmit are actually received. We won't need the Internet to demonstrate. Suppose that I have a nice fast PC and a 1000baseT switched Ethernet LAN, in another office a friend has an older Mac with 100baseT connected to the LAN. I have a hypothetical TCP/IP without congestion management, let us call it Slough (as a contrast to names like Vegas or Reno which are used for real algorithms).

I want to transfer a file to the Mac. Slough on my PC just sends all the packets with the file data in as quickly as possible over its Ethernet. Obviously 1Gbps will not fit into 100Mbps and so the switch or router between the PC and Mac must drop 90% of my packets, even with say 1MB of RAM just for buffering this nonsense, it will fill almost immediately and have to drop further packets. Because Slough has no congestion management it doesn't do anything about that - eventually the fact that most packets weren't received gets back to the sender (because they aren't ACKed), and Slough just retransmits them in the same fashion continuing at 1Gbps. Although Slough saturates my link at 1Gbps, the actual data transfer rate of the Slough TCP/IP will drop to a trickle, with most packets being transmitted many times before finally arriving. Even if the switch has a huge buffer, that just confuses the issue, with some packets being received after they've been retransmitted or arriving out of order, reducing transfer speeds even more.

So, now hopefully you see that congestion management is effectively mandatory in TCP/IP, and thus why yes, the right thing (not to mention eventually the only thing) for a router to do about congestion is to drop packets. And in practice congestion will happen. Some ISPs aim to avoid it within the systems under their control, but that's aim and under their control not promise and across the entire Internet.

Other Internet protocols fall roughly into two camps. Very lightweight low bandwidth protocols like DNS that should never saturate any useful link and protocols which have their own congestion management usually cut-and-paste from TCP.

Reading some more of these posts I suspect, tialaramex, most of our disagreement came down to misunderstanding.

I thought you were referring to core / transport network, not CPE, as we were discussing FTTP and FTTC.

I entirely recognise that some implementations of IP stacks on CPE are nothing short of banal and indeed the only real way to resolve them is to fix them on the kernels that these CPE are built on. The developers of CPE firmware rarely show any interest so best to simply take it out of their hands.

Such issues on edge and core carrier/enterprise class routers are absolutely inexcusable, not that they haven't happened of course...

My expertise lies at that stage and I am familiar but definitely not an expert with consumer CPE. I have done plenty with HSTCP and MX-TCP of various varieties along with the occasional bit of fun with satellite and other things however consumer grade CPE are something of a dark art and I'm happy to defer to you on those.

In reply to a post by Chrysalis:

did verizon in america even state FTTP paid for itself by the reduced maintenance costs?

Have you seen a FIOS install? They don't protect the fibre. You can get at it. If you're really unlucky they wrap the excess around the externally mounted ONT. Mind you the yanks seem to have this approach to infrastructure anyway. I doubt it took them long to install. I think BT are missing a trick!

They do have battery backup which is (on my bros house) installed internally on the property close to the ONT. The ONT is an Alcatel Lucent cable box. The house is then wired with COAX. The STB's are all very nice Cisco jobs. The CM I think is Alcatel.


Regards,


Gareth