dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1014

Sandroid
BSD geek
Premium Member
join:2002-08-08
Anjou, QC

Sandroid

Premium Member

RFC 4638 and Teksavvy

Anyone know if this is supported?

My cellpipe only has 100mbit lan so it's not technically feasible, but if TSI supports it, and there are alternative modems in existence that I can acquire and use in place of the cellpipe, I'd be first in line.

Anyone have anything useful to share on this?

derekm
join:2008-02-26

derekm

Member

+1

TSI Jonathan
Premium Member
join:2011-08-24
Chatham, ON

2 edits

TSI Jonathan to Sandroid

Premium Member

to Sandroid
Hello,

Just to confirm, is this for a business? If it is I will ask our business department to look into this for you.

EDIT: I'll let TSI Gabe jump on this one since he knows more about it.

Thank you,

TSI Jonathan

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt to Sandroid

Premium Member

to Sandroid
The Sagemcom (which is now provided in place of the Cellpipe) have gigabit ports.

TSI Gabe
Router of Packets
Premium Member
join:2007-01-03
Gatineau, QC

TSI Gabe

Premium Member

I'm not sure I'm following, the RFC in question is basically to allow an MTU of 1500 which doesn't really have anything to do with a 100Mbps/1Gbps port.

derekm
join:2008-02-26

derekm

Member

Gigabit implies jumbo frame support.

There are only 'oversized' out-of-spec frames in 100BaseT.

EDIT: you need to be able to send/receive larger than 1500 byte frames from the CPE router to the modem for the RFC to make any sense.

Sandroid
BSD geek
Premium Member
join:2002-08-08
Anjou, QC

Sandroid

Premium Member

Hey Gabe,

I'd be doing this on OpenBSD and on that OS, it's as simple as setting the physical-if to MTU 1508, and the pppoe pseudo-if to 1500, and restart networking services. I've tried it and noticed that a tcpdump during the session initiation shows that I'm still limited to a max payload of 1492 in the discovery phase. (the same person that implemented this on OpenBSD patched tcpdump to show this info). What's not clear is if that's a result of the portspeed limitation on the cellpipe preventing larger than 1500MTU packets, or if TSI only works with the traditional 1500byte packet that has an encapsulated payload.

Having this would make life easier for sure. Since moving from HSA I noticed that I had to add a couple of scrubbing rules to my firewall, and that triggered issues with some IM protocols and so on... just messy

Inssomniak
The Glitch
Premium Member
join:2005-04-06
Cayuga, ON

1 edit

Inssomniak

Premium Member

said by Sandroid:

Hey Gabe,

I'd be doing this on OpenBSD and on that OS, it's as simple as setting the physical-if to MTU 1508, and the pppoe pseudo-if to 1500, and restart networking services. I've tried it and noticed that a tcpdump during the session initiation shows that I'm still limited to a max payload of 1492 in the discovery phase. (the same person that implemented this on OpenBSD patched tcpdump to show this info). What's not clear is if that's a result of the portspeed limitation on the cellpipe preventing larger than 1500MTU packets, or if TSI only works with the traditional 1500byte packet that has an encapsulated payload.

Having this would make life easier for sure. Since moving from HSA I noticed that I had to add a couple of scrubbing rules to my firewall, and that triggered issues with some IM protocols and so on... just messy

The PPPoE server would have to be configured for MTU max of 1500 byte packets, Im sure its not. The whole path would have to support the oversized packet size.

You are probably talking about MSS rules when you mention "scrubbing".
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson to Sandroid

Member

to Sandroid
I'm not following the question either. Even the 10/7 I'm using with a Sagemcom PPPoE sets MTU to 1492 like the old 1M DSL days. The last thing I'd do is to use the DSL modem as a switch, it lives off the WAN port of my router. I don't see any way to change what we get. You can do what you want on the LAN side.

On that note I really do wish we had a choice with modems. The cellpipe and sagemcom are both consumer grade all in one junkers when all I want is a dumb modem.

nitzguy
Premium Member
join:2002-07-11
Sudbury, ON

nitzguy to Sandroid

Premium Member

to Sandroid
The OP was on the really old HSIA service that didn't use PPPoE...

Unfortunately....with the move to PPPoE, you've entered the world of a 1492 MTU (which wasn't the case with the old service I believe)...

So, long story short, I think you're stuck

Sandroid
BSD geek
Premium Member
join:2002-08-08
Anjou, QC

Sandroid

Premium Member

said by vikingisson:

I'm not following the question either. Even the 10/7 I'm using with a Sagemcom PPPoE sets MTU to 1492 like the old 1M DSL days. The last thing I'd do is to use the DSL modem as a switch, it lives off the WAN port of my router. I don't see any way to change what we get. You can do what you want on the LAN side.

Packet leaves your PC. It is a full 1500 byte frame. Traverses your switch. Still 1500 bytes. Reaches your router. Oh shit moment. Time to split the packet in two because there's only 1492 bytes of space inside a PPPoE frame to transport data. It's a question of efficiency. Some protocols get affected by this, and if you're trying to keep your traffic "clean" this winds up looking dirty

On that note I really do wish we had a choice with modems. The cellpipe and sagemcom are both consumer grade all in one junkers when all I want is a dumb modem.

I don't think you realize the repercussions of shrinking the MTU. I think we should consider it *ideal* to achieve the same MTU across the network, so that you don't have to split up packets and what not. Nothing about this RFC has any provision for using the modem as a switch (not sure what you mean by that), and whether you use the modem as a router or just a bridge makes no difference aside from the fact that the modem firmware may or may not support this larger frame size.

The goal isn't to get a specific frame size across the board per se, it's more to remove the environment where packets need to be truncated/fragmented, or whatever else to fit into the standard mtu size.
said by nitzguy:

The OP was on the really old HSIA service that didn't use PPPoE...

Unfortunately....with the move to PPPoE, you've entered the world of a 1492 MTU (which wasn't the case with the old service I believe)...

So, long story short, I think you're stuck

This *is* RFC'd and in use by several ISP's... I don't think I'm stuck - we just need TSI to get on board
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned) to derekm

Member

to derekm
said by derekm:

Gigabit implies jumbo frame support.

That's an assumption. The Ethernet spec does not define Jumbo frames. It just happens that most vendors have implemented Jumbos but even then they don't agree on the sizes supported. Some GigE chipsets do not support Jumbos at all.
34764170

34764170 (banned) to Inssomniak

Member

to Inssomniak
said by Inssomniak:

The PPPoE server would have to be configured for MTU max of 1500 byte packets, Im sure its not. The whole path would have to support the oversized packet size.

Yes, it would; if the client indicates it has RFC4638 support. That's the whole point. When the path from the ISP to the DSLAM is all GigE/10Gb Ethernet it would not be an issue.

Inssomniak
The Glitch
Premium Member
join:2005-04-06
Cayuga, ON

Inssomniak

Premium Member

said by 34764170:

said by Inssomniak:

The PPPoE server would have to be configured for MTU max of 1500 byte packets, Im sure its not. The whole path would have to support the oversized packet size.

Yes, it would; if the client indicates it has RFC4638 support. That's the whole point. When the path from the ISP to the DSLAM is all GigE/10Gb Ethernet it would not be an issue.

Is this the case anywhere? That TSI or any ISP using bell last mile gets GigE or better right to the DSLAM?

Im under the impression that this RFC can never work with Bell right now.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson to Sandroid

Member

to Sandroid
said by Sandroid:

I don't think you realize the repercussions of shrinking the MTU. I think we should consider it *ideal* to achieve the same MTU across the network, so that you don't have to split up packets and what not. Nothing about this RFC has any provision for using the modem as a switch (not sure what you mean by that), and whether you use the modem as a router or just a bridge makes no difference aside from the fact that the modem firmware may or may not support this larger frame size.

The goal isn't to get a specific frame size across the board per se, it's more to remove the environment where packets need to be truncated/fragmented, or whatever else to fit into the standard mtu size.

Sure I understand the technology. I'm saying this isn't what's happening and we can't do anything about it unless TSI *and* Bell decide to make it so. And that's highly unlikely.

"They have the internet on computers now!" ---Homer
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned) to Inssomniak

Member

to Inssomniak
said by Inssomniak:

Is this the case anywhere? That TSI or any ISP using bell last mile gets GigE or better right to the DSLAM?

Im under the impression that this RFC can never work with Bell right now.

The ISP side has been Ethernet for many many years. The FTTN remotes are Ethernet fed. They're using Juniper gear for BRAS' so those should be running 10Gb Ethernet interfaces by now. So yes in theory this is possible.
OHSrob
join:2011-06-08

3 edits

OHSrob to Sandroid

Member

to Sandroid
Bell's dsl aggregation network supports MTU's over 1500 bytes both on the old ATM network and on the new FTTN network. (Including in area's with old OC3's feeding the co's).

I use to use a 1500byte MTU with caneris with zero issues. This lack of jumbo MTU support is likely on teksavvy's end.

edit: I have since replaced my Caneris ML-PPP with a 100megabit optical gigabit service from nexicom.

Caneris's ML-PPP implementation scales very nicely to 16 lines as well. They have one of the most reliable and versatile LNS I have ever had the pleasure of connecting to.

edit: I never tested an MTU of 1500 on a single line, it was always on 4+ lines.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned)

Member

said by OHSrob:

Caneris's ML-PPP implementation scales very nicely to 16 lines as well. They have one of the most reliable and versatile LNS I have ever had the pleasure of connecting to.

edit: I never tested an MTU of 1500 on a single line, it was always on 4+ lines.

But that is because you were using MLPPP. That is a different scenario. MLPPP allows for fragmentation and reassembly. Thus allowing for much much larger frames to be passed down the connection.

The point of RFC4638 is to both increase the MTU and stop the packet fragmentation.

nitzguy
Premium Member
join:2002-07-11
Sudbury, ON

nitzguy to Sandroid

Premium Member

to Sandroid
said by Sandroid:

This *is* RFC'd and in use by several ISP's... I don't think I'm stuck - we just need TSI to get on board

...I'm sure they'd be happy to....I feel like it might not be an overnight switch however . Maybe you will be the guinea pig? I'm sure they'd be happy to have one lol.

Sandroid
BSD geek
Premium Member
join:2002-08-08
Anjou, QC

Sandroid

Premium Member

I'll ask in the direct forums and post the response here. I wanted to do it here because I suspected others would want to know too, but no official word from TSI here yet.