@wombat @ejs
I really do think may be something in the theory about deliberately making the packet size smaller on slower links. Unfortunately I have quite a bit going on right now and I'm not in a position to be able to research or take onboard new info.
Serialisation is an issue on networks. Using the standard formula:
Serialization Delay (secs) = Size of Packet (bits) / Transmission Rate (bps) Serialisation causes delay on a 1 Mbps link is 12ms, yet its 24ms for a 500kbps link*. Therefore the slower the link the more advantageous it is to use smaller packets.
The latency problem results from the fact that an entire
packet must be received for its content to become
available to an application. In Ethernet terms, “entire
packet” means up to 1500 bytes, while in ATM the unit
of transferred data is only 53 Bytes. On a typical ADSL
link, running at 1 Mbps, the time to transfer 1500 bytes is
12 ms. It is clear that queuing alone could consume a
large portion of the delay budget of a time-critical
application such as a voice connection.
5. Conclusions
The ATM-TC and PTM-TC layers defined for Digital
Subscriber Line systems both have their advantages and
disadvantages for the transport of Ethernet frames on the
local loop. At low bitrates, latency becomes an important
issue, which is best dealt with by ATM, because of its
small PDU size. When different types of service are
converged on the same channel, ATM is best equipped to
guarantee the QoS requirements of each individual
service. At high bitrates latency becomes somewhat less
important, and the reduced overhead of PTM is a distinct
advantage, provided that the necessary OAM&P tools are
in place. The functionality of the ATM-TC and PTM-TC
layers is comparable in terms of mechanisms for frame
delineation, error detection and rate decoupling. The flow
control mechanisms are also similar, but due to the larger
granularity of Ethernet frames, larger buffers will be
required than in the case of ATM.
So we have ethernet at home, we have fast speeds on the 21CN backhaul, and also on the internet. The bottleneck is the physical DSL link ie between modem <-> DSLAM over the copper wire. So something has to happen otherwise there is going to be some huge latency incurred over this part of the link. Traditional ADSL used ATM framing of just 53 bytes, yet PTM uses anything up to 1500 bytes (same as ethernet).
For adsl (ATM) we have the
ATM adaptation Layer (AAL5). AAL specifically segments and reassembles the higher layer packets into ATM cells for transfer over the ATM part of the link. In laymans terms AAL5 is responsible for chopping up ethernet size packets for transmission over the DSL link and reassembling at the other end. Thus ensuring serialisation is less of an issue over the DSL part of the link and reducing latency.
So the next question is what happens with VDSL framing and PTM. Look at stats, quite obviously some sort of framing is still going on - probably one of the
HDLC subsets. Even on my 80Mbps link, the VDSL frame size is still restricted to just 255/240 bytes.
I also just noticed npr's post
here. Yet another long line with upload speed of less than 1Mbps and an N value of just 19. No R value though.
These small frames sizes appear to be used on slow links. I have no idea what defines the smaller frame sizes other than it does appear to be smaller frames for speeds of less than ~1Mbps. As I mentioned in my previous post when on adsl my 'K' value for 832 upstream was 27.
Calculations
(1500 bytes * 8) / (1Mbps *1,000,000) = 12000 / 1,000,000 = 0.012 secs = 12ms
Serialisation delay on a 0.5Mbps link = 12000 / 500,000 = 0.024 = 24ms
