Zen and RFC 4638 Baby Jumbo Frames

Sadly, Zen has dropped support for RFC 4638 as of a week or so ago.

I know this for sure on ADSL, not too sure about Fibre.

I had an email from Zen confirming there will be an "upgrade" and as such my internet may wobble for a bit about a couple of weeks ago, since then my router will not use RFC 4638. Setting it by force causes packet loss.

Called Zen's technical team earlier and confirmed they have dropped RFC 4638.

No idea why they would downgrade their service in this way. I asked if they would ever switch it back on and they said no.

Shame...

I am posting this to stop anyone spending hours messing with OpenWRT wondering why they can't get this functionality working. Its them, not you

Is this on Zens own backhaul only or also on BT?

Interesting, I don't currently use baby jumbo frames but I had considered trying it out as I imagine my EdgeRouter would do this if I wanted it to (via HG612). If FTTC also has lost this (via Zen's back-haul) then I won't be ever trying that for the remainder of the contract term.

Hi,

I don't post here too often as my colleague Andy has been picking things up - but I've just noticed this thread. I'll take a look into this and post back.

Cheers,

Jon

In reply to a post by rlees85:

Sadly, Zen has dropped support for RFC 4638 as of a week or so ago.

I know this for sure on ADSL, not too sure about Fibre.

I guess if you need passthrough from something pretending to be a modem or Zen are "special" for ADSL then fair enough, but ...

Why would anyone in normal setups be using pppoe(oa) on adsl anyway.
pppoa vcmux is more efficient and should be OK at 1500 MTU without anything special needed.

Edit: Though with adsl pppoe vc mux running 1478 MTU or MSS clamp is slightly more efficient than 1500.

Edited by deleted (Mon 09-Oct-17 23:42:10)

It is using BTs backhaul, be great of Zen do change their mind...

I'm not an expert in MSS/Clamping but I am sure that PPPoA is supposed to be even more inefficient than PPPoE with standard 1492.

In reply to a post by rlees85:

It is using BTs backhaul, be great of Zen do change their mind...

I'm not an expert in MSS/Clamping but I am sure that PPPoA is supposed to be even more inefficient than PPPoE with standard 1492.

MSS clamping is a bit OTT unless you know iptables. If you are using a MTU < 1500 your router will probably do it for you.

On ADSL pppoe isn't just pppoe as it is on FTTC, it's still got to go over aal5 and ATM which means it's at least 22 bytes per packet more fixed overhead than pppoa vc multiplex.
Depending on packet size there will be some additional variation for both as AAL5 pads out to fit a whole number of ATM cells, but for ADSL it is less efficient.

Interesting.... ISPs and BT are never that forthcoming with technical details like that. Last time I checked people seemed to recommend PPPoE even on ADSL connections but after another look around it seems you are right and generally all ADSL stuff goes over ATM anyway.... thanks for the info

Are you sure your information applies to 21CN?

The 21CN network was built from the start to support PPPoE and this is actually the preferred connection method but they also detect and support any PPPoA connections for backwards compatibility.

Edited by deleted (Wed 11-Oct-17 16:51:55)

Source for quote?

I guess there is scope for confusion, but AFAIK 21cn is ethernet based teleco side and 20cn was ATM further into their network.

For ADSL even on 21cn your modem is still using ATM till it gets to the exchange, so pppoe in that case is pppoeoa = more overhead than pppoa.

For VDSL modems on FTTC there is no ATM, it's PTM which is a bit more efficient for "on the wire" overheads.

FWIW BT do go into some detail, you just need to know where to look =

http://www.sinet.bt.com/sinet/SINs/pdf/472v2p8.pdf

Top of page 13 -

"It should be noted that the use of LLC/SNAP and PPPoE incur a higher protocol overhead and
therefore will provide a lower throughput than the use of PPPoA/VC-mux."

As it says on page 12 that pppoe is llc/snap my previous extra overhead figure is now increased by 8.