[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SIG-IX] Jumbo Frames on IX
Dear Raphael,
> Now for another poll $,1rs(B on our new exchange in Hong Kong...
>
> 1. Is there value in enabling Jumbo Frames on the exchange?
>
> 2. If yes, what sized Jumbo frame do you want?
> a) 1600 (baby giant)
> b) 4470 (legacy MTU of FDDI, now default for POS links)
> c) 9180 (RFC1209)
> d) Other (please specify)
Another question delived from your question 1 is "Is there any
ISP that support jumbo frames?"
DIX-IE in Tokyo doesn't support Jumbo at this moment. We had
no specific request for it.
Currently FTTH services available in Japan offer 1500byte MTU,
inclusive of PPPoE overhead. So the end-to-end MTU is less
than 1500. So there is no strong requiement for IX to support
Jumbo. As the CPUs in these days are fast enough to deal with
standard MTU at the FTTH speed, there would be few necessity
to use Jumbo, IMHO.
R&E networks are the exceptions. Many R&E networks support Jumbo
of about 9000 bytes (various devices have different MTU value
and it is hard to have a common number). So many R&E exchanges,
including StarLight in Chicago, NetherLight in Amsterdam, MANLAN
in New York, and Pacific Wave in Seattle/Los Angeles support
Jumbo (in a case of Pacific Wave, there are two different VLANs
configured -- one for standard MTU and another for Jumbo), and
it is up to R&E ISPs negotiation which VLAN the BGP peer uses.
This is because some off-the-shelf applications such as
uncompressed HDTV transmission (requires 1.5Gbps) in bidirectional
manner implemented in a high-performance PC still require Jumbo.
When all of the TCP/IP processing can be off-loaded, and when
the CPU performance increased, or when only one-way transmission
is required, some of such applications may run on a starndard
MTU path.
It is users' responsibility to see if the path has required MTU.
I understood that micro-jumbo (1600) helps to provide 1500 byte
MTU for a tunnel of various kind, however, it may not be welcome
as 3rd party can use the bandwidth.
-- Akira Kato, WIDE Project
