WAN Ethernet / VPLS: Is overhead an issue?

We're in the midst of a most interesting conversation at Webtorials on the subject of "Wide Area Ethernet / VPLS - Ready for Prime Time?" This conversation features an in-depth online interview with Geoff Kreiling, Manager - Product Development, at Masergy.

We're in the midst of a most interesting conversation at Webtorials on the subject of "Wide Area Ethernet / VPLS - Ready for Prime Time?" This conversation features an in-depth online interview with Geoff Kreiling, manager - product development, at Masergy.

One topic that we found to be particularly of interest was the question of the pricing and overhead. In particularly, we asked Geoff, sssuming that the service pricing is usage-based, how do you account for the relatively high overhead of Ethernet packets as compared with protocols such as MPLS - and even TCP/IP? (In general, these "legacy" protocols would strip out the overhead of the "native" header at one end and re-insert at the other. Thus, does the Ethernet packet size present a challenge and how do you address this?

Geoff replied, "Overhead for Ethernet WANs is similar to that required for customers' own LAN. Pricing is based upon L2 packets. Customers ask for 10G, 1G 10M, 1M circuits, not 10G, 1G, 10M, 1M of payload throughput. How exactly would you sell 1G of payload throughput on a 1G circuit without incurring latency?

"A larger concern is the increased overhead required for IPv6, but the issue becomes noise at higher circuit capacities and maximum frame sizes. It is critical to avoid the need for fragmentation at higher protocols.

"Ethernet packet size presents a challenge in a limited fashion. It is a matter of sufficient product documentation to educate the end customer. Most customers are familiar with additional overheads required with VoIP traffic as a simple example and adjust their required QoS subscriptions accordingly."

And while we agreed with IPv6 being a concern so far as packet size is concerned. We asked Geoff to expound further on overall price per bit per second. After all, when using Frame Relay or ATM, all higher level overhead (such as TCP/IP) was essentially stripped off before the packets entered the network interface and regenerated on the other end. Even with an IP-based service, the MAC layer is stripped off. However, with an Ethernet "port," the entire packet including the MAC layer is included in the "port size."

So the fundamental question is whether there's a rule of thumb for comparing price per bit per second when comparing the price for an "Ethernet port" as compare to an "IP port" or an "ATM port" since more overhead is going across that interface?

Geoff further explained, "We are not concerned with the size or overhead associated with an IP or Ethernet packet per se. When we are building a solution for a customer we sell an access type and a port speed based on the bandwidth requirements of the customer. So if the customer needs 12 Meg of bandwidth at a site we sell them 12 Meg of bandwidth. Our pricing and sales strategies revolve around sizing the bandwidth needed to the application(s) the customer is running."

Many thanks to Geoff for sharing this insight. And we think the bottom line here is that it's up to the network planner to consider the overhead of the protocol used at the interface as a part of the cost per bit per second.

Please feel free to comment and/or ask further questions by joining this discussion.

Learn more about this topic

100 Gigabit Ethernet: Bridge to Terabit Ethernet

Slideshow: Evolution of Ethernet

10G, 40G Ethernet to grow at rapid clip despite economy, study says

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT