Assuming that your 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 fact, several of the "legacy"
protocols would strip out the TCP/IP header at one end and re-insert at
the other.
Does the Ethernet packet size present a challenge? How do you address this?
Does the Ethernet packet size present a challenge? How do you address this?
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.