4 ms·
Some of that is down to the PPPoE standards. I added RFC4638 support to the OS that I use but don't know how ISPs that don't support it will respond.
by rjsw 5y ago
Some of that is down to the PPPoE standards. I added RFC4638 support to the OS that I use but don't know how ISPs that don't support it will respond.
- netr0ute 5y agoI'd expect those ISPs to use jumbo frames only where they use PPPoE so that it looks "transparent" to non-PPPoE traffic.
- deleted 5y ago[deleted]
- rjsw 5y agoThat is the whole point of RFC4638, it allows you to request an MTU of 1508 for the PPPoE connection so that the tunnelled frames can be 1500 bytes. The problem is that it tries to be backwards compatible which makes it hard to deal with this request not getting granted.
- bcrl 5y agoI've tried to detect MTU on PPPoE sessions with LCP echo requests, and it works... Until I came across consumer wireless routers that send back short LCP echo replies to 1500 byte LCP echo requests. Sometimes software is such complete garbage in the real world.
- toast0 5y agoWell yeah, PPPoE is super derpy; but at least the modems could be trained to adjust MSS on the way in and out to (tcp) 1472, but they often don't, and sometimes only adjust mss on the way out, not on the way in. My current PPPoE ISP doesn't support RFC4638, and my previous ISP was worse, I had a fiber connection with 1500 MTU, but their 6rd gateway was only 1492 MTU (so ipv6 MTU was 1472 after the tunnel) and ICMP needs frag was rate limited, so IPv6 would only sometimes work until I figured out I needed to adjust the v6 MTU. Did you know Windows doesn't request (or process) MTU information on v4 DHCP? That's a nice touch.
- philjohn 5y agoAnd without dedicated packet processing chips it's a nightmare on anything >= 1Gbps