dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
2
share rss forum feed


squircle

join:2009-06-23
Oakville, ON

1 edit
reply to dsiemon

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

VDSL2 doesn't use ATM. The only overhead is from the PPP headers (which is why your MTU is 1492 instead of 1500), but your sync rate usually compensates for this (e.g. my 25/10 connection syncs at 27/11.3). Your routing equipment should recognize that the MTU of the VDSL2 interface is 1492 bytes and fragment larger packets appropriately. Also, your 25/7 service should be 25/10 (as Bell is upgrading everybody's connection last I saw), but it may not have been deployed in your area yet (although I thought it was everywhere).

dsiemon

join:2012-09-26
Where does 1480 come from?

I can ping with 1464 data bytes for a total IP packet size of 1492 [1] to a remote host and the packet's aren't fragmented.

[1] - 1464 + 20 for the IP header + 8 for the ICMP header

Isn't PPPoE overhead 8 bytes?


squircle

join:2009-06-23
Oakville, ON
Bleh, you're right. I've been working with too many numbers tonight (just ask my copy of MATLAB). I've edited my post; you're right, it's 8B, not 20.

dsiemon

join:2012-09-26
I need to do some more testing but it looks to me that there is more overhead than just 8 bytes. See page 48 at the link below for some details of how much per packet overhead there is on ADSL. I'm looking for that level of detail for VDSL2 w/ Bell.

»web.archive.org/web/200904221315···/thesis/


squircle

join:2009-06-23
Oakville, ON
Well the advantage of VDSL2 is that it is much closer to being end-to-end ethernet than ADSL. There's no ATM/AAL5 to worry about (i.e. your 1500 byte packets aren't being chopped into 31 (and a bit) ATM cells), removing the layer that has historically made ADSL connections "lower than advertised."

If you're looking for delay products and such, your best starting point is your line stats on your Cellpipe. If there isn't any upstream/downstream delay, it means there's no interleaving and the WAN link should behave similarly to an ethernet network (VDSL2 even supports VLANs natively). If there is interleaving, that's when the calculations about upstream/downstream delays and such come into effect.

Basically, your VDSL2 modem differs from your ADSL modem in that an ADSL modem is an ethernet to ATM bridge, whereas a VDSL2 modem is an ethernet to ethernet bridge.


QuantumPimp

join:2012-02-19

1 edit
IEEE 802.3ah has defined a specific Ethernet TPS-TC using the 64/65-octet encapsulation for Ethernet applications without underlying ATM.

I have no idea how 64/65-octet encapsulation works.


squircle

join:2009-06-23
Oakville, ON
reply to dsiemon
Okay, so here's the deal. I was told that there is no penalty for small packets because the 64/65 octet stream can shrink dynamically to encapsulate packets of smaller size. Furthermore, the 802.3 layer does not fragment packets, even those at full ethernet MTU (1500 B). There is no additional overhead/delay introduced by the 802.3 layer. 10PASS-TS essentially removes the need for ATM as the transport layer.

He says the best way to operate is to leave the MTU at 1492 and assume that no frames are padded out (of course, unless they're smaller that 46 B, which is the minimum frame size defined by 802.3) and that there are no extra headers/trailers added to the frame as it traverses the DSL link (as the FEC must be calculated for each frame regardless of size). Since VDSL2 is full-duplex (using FDD), there's no need to worry about packet queuing due to blocking.

This is pretty much all I remember; he threw a lot of information at me and I think I got the gist of it and relayed it (hopefully) adequately. If he or I can clarify anything else, let me know.

dsiemon

join:2012-09-26
Thanks for the info, very useful. However, I don't understand why I should assume no padding. At least the 8 PPPoE bytes are there. From the standpoint of shaping on the ppp0 interface on my Linux router I suspect that I need to add the 802.3 overhead as well but I'm not sure.

Also, my Cellpipe says:

Upstream line rate 7344 kbps
Bearer Upstream payload rate 6560 kbps

What causes this difference? Is it the 802.3 overhead?


squircle

join:2009-06-23
Oakville, ON
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
"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
Oakville, ON
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
kudos:8
Reviews:
·Primus Telecommu..

4 edits
reply 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
reply 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

join:2012-09-26
reply 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