dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
16

squircle
join:2009-06-23
OTWAON10

squircle to dsiemon

Member

to dsiemon

Re: [Internet] Per packet overhead on Bell's VDSL? ATM based?

I'm sorry, I didn't make the best distinction between padding and overhead. Frames aren't padded out (with 0's) when they're sent over the wire, but overhead is still there. You have to assume no additional overhead beyond your upstream/downstream payload rates (as listed by your Cellpipe); it's 802.3 on both sides.

From your Linux router's standpoint, small packets are still always padded out to 64B (realized I said "46" in my last post, sorry), so the modem doesn't have to add anything when it sends the frame over the wire.

As for the difference between the line rate and payload rate, the difference is caused by the encoding on the line and error correction stuff (which is how xDSL is so resilient against line noise). Luckily you don't have to do any of those calculations; they're done for you in your modem's interface (and agreed upon by both the near and far ends).
dsiemon
join:2012-09-26

dsiemon

Member

"You have to assume no additional overhead beyond your upstream/downstream payload rates (as listed by your Cellpipe); it's 802.3 on both sides."

"As for the difference between the line rate and payload rate, the difference is caused by the encoding on the line and error correction stuff (which is how xDSL is so resilient against line noise). Luckily you don't have to do any of those calculations; they're done for you in your modem's interface (and agreed upon by both the near and far ends)."

These seem contradictory to me. However, I think maybe we're talking about overhead at different locations so let me clarify that I'm trying to figure out the number of bytes added to an IP packet.

More questions:
- Does payload rate include 802.3 overhead or just the encoding on the line? I'm guessing the later based on some experiments I've done.
- Is the full 802.3 header transmitted over the VDSL link?
- 7 bytes preamble
- 1 byte start of frame
- 6 byte D MAC
- 6 byte S MAC
- 2 byte Ethertype
- 2 byte 802.1Q tag
- 4 byte FCS
- 12 byte Interframe gap
Total: 40 bytes

+ 8 for PPPoE gives me a total per packet overhead of 48 bytes.

squircle
join:2009-06-23
OTWAON10

squircle

Member

said by dsiemon:

let me clarify that I'm trying to figure out the number of bytes added to an IP packet.

Well then, let's go question-by-question:
said by dsiemon:

More questions:
- Does payload rate include 802.3 overhead or just the encoding on the line? I'm guessing the later based on some experiments I've done.

It includes the full 802.3 overhead; payload in this case is IP packets in 802.3 frames.
said by dsiemon:

- Is the full 802.3 header transmitted over the VDSL link?
- 7 bytes preamble
- 1 byte start of frame
- 6 byte D MAC
- 6 byte S MAC
- 2 byte Ethertype
- 2 byte 802.1Q tag it's 4 and always will be
- 4 byte FCS
- 12 byte Interframe gap
Total: 40 bytes

+ 8 for PPPoE gives me a total per packet overhead of 48 bytes.

You're comparing apples to oranges. 8 bytes for PPPoE gives you a total packet overhead of 8 bytes. That's it. Nothing more. At all. Period. There are 40 bits added to the frame, but you also seem to be under the impression that the frame is subject to the IP MTU which it is not. Wireline frames don't care about what protocol is running atop them.

This means your 1492 + 8 byte IP packet becomes (1500+7+1+6+6+2+4+12=) 1538 bytes on the wire.

So if you're looking for per-packet overhead, it's 8 bytes, just like I said in the beginning. The rate of 1492-byte IP packets on the WAN is given to you by the payload rate of your modem. When you're doing calculations for shaping, ignore 802.3 overhead (as most guides from commercial appliances will tell you). Shaping is done a layers higher than data link, acknowledging that framing will always be there and doesn't actually add anything to the packet. Nothing useful comes from caring about 802.3 overhead (not even for small packets).

I talked to the person who managed our massive Sandvine boxes here, and he said that you're wasting your time worrying about 802.3 stuff for small-packet performance; he says to "just treat them like any other packet because that's what every other device does."

HTH.

xsbell
join:2008-12-22
Canada

4 edits

xsbell to dsiemon

Member

to dsiemon
said by dsiemon:

These seem contradictory to me. However, I think maybe we're talking about overhead at different locations so let me clarify that I'm trying to figure out the number of bytes added to an IP packet.

We're talking about loop aggregation (between the modem and DSLAM), while I think squircle is talking about link aggregation.

To answer your original post, Bell does indeed still use ATM for their backhaul (link aggregation), but all the newer remotes use Ethernet. (GigE)

The difference between ATM and PTM overhead is that PTM introduces one flag octet (on average), one address octet, one control octet and two CRC octets, which adds up to five octets. In addition to this, HDLC encapsulation changes every occurrence of the octets 0x7D and 0x7E in a two-octet sequence, to avoid interpreting data octets as closing flags. This causes an average increase of 0.78% for random data. Applying HDLC encapsulation to packets within the Ethernet length range (64–1522 octets) results in an expansion of 1.11%–8.59%.

AAL5 over ATM consists of adding a protocol trailer (1 octet of User–User information, 1 octet CPI, a 2-octet length field, and a 4-octet CRC), and a padding to make sure the total packet length is an integer multiple of 48 octets (the payload size of an ATM cell). The actual ATM overhead consists of 5 octets per cell. Applying this encapsulation to packets within the Ethernet length range results in an expansion of 12.67%–63.90% (using an average padding of 23 octets).
dsiemon
join:2012-09-26

dsiemon to squircle

Member

to squircle
Does payload rate include 802.3 overhead or just the encoding on the line? I'm guessing the later based on some experiments I've done.
I wasn't precise enough with this question. What I should have asked is does the difference between the sync rate and the payload rate include the 802.3 overhead. From your response I gather you agree that it doesn't. The alternative doesn't make sense because the amount of overhead has to vary by the size of the packet. There is a fixed 802.3 header added to a variably sized IP packet. Unless the payload value is an average or something like that it cannot reflect 802.3 overhead without assuming a fixed IP packet size (802.3 header / IP packet size is not constant).

Ooops, you are right about the 802.1Q field size. So 42 for 802.11 and 8 for PPPoE for a total of 50.
You're comparing apples to oranges. 8 bytes for PPPoE gives you a total packet overhead of 8 bytes. That's it. Nothing more. At all. Period. There are 40 bits added to the frame
From the perspective of the PPPoE interface on my home router everything beyond the IP packet is overhead. The bit rate limit is applied to the PPPoE interface. Since the overhead bytes are transmitted on the wire they affect the total 'real' bandwidth available and must be taken into account for optimal shaping. Otherwise the shaper will overshoot the bandwidth available.

I've always seen the term frame used to talk about the Ethernet header + payload so your comment about 40 bytes added to the frame doesn't make sense to me.
but you also seem to be under the impression that the frame is subject to the IP MTU which it is not.
Not at all.
This means your 1492 + 8 byte IP packet becomes (1500+7+1+6+6+2+4+12=) 1538 bytes on the wire.
Aren't you missing the 802.1Q bytes there? Ignoring that, the above calculation is 46 bytes of overhead on top of each IP packet.

To summarize:
- The difference between sync rate and payload rate is DSL error correction overhead.
- The payload is the entire 802.3 frame including FCS, inter frame gap etc.
dsiemon

dsiemon to xsbell

Member

to xsbell
Thanks for the info on PTM overhead though I'm now confused as to whether this is included in the difference between the sync and payload rates