Jumbo-to-Regular frame bridge

G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

Hello!

Our newer computers tend to come with NICs, that can handle big frame sizes
(at least 8 or 9 K, some even 15). We also have one 24-port switch, that
can handle 15K frames. But many desktops and the older servers can't handle
the frames above the 1500 bytes, of course, so the entire network is still
limited to the small frame size.

We could setup a small PC running something like FreeBSD to transparently
fragment packets from one interface to another, but I'm wondering, if such
devices are already available out there... Thanks!

-mi
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <15198068.kmfYAppCL7@Misha>,
Mikhail Teterin <usenet@aldan.algebra.com> wrote:
:Our newer computers tend to come with NICs, that can handle big frame sizes
:(at least 8 or 9 K, some even 15). We also have one 24-port switch, that
:can handle 15K frames. But many desktops and the older servers can't handle
:the frames above the 1500 bytes, of course, so the entire network is still
:limited to the small frame size.

I thought this was the kind of situation that MTU path negotiation
was invented for?
--
Strange but true: there are entire WWW pages devoted to listing
programs designed to obfuscate HTML.
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

Mikhail Teterin <usenet@aldan.algebra.com> wrote:
> Hello!

> Our newer computers tend to come with NICs, that can handle big frame sizes
> (at least 8 or 9 K, some even 15). We also have one 24-port switch, that
> can handle 15K frames. But many desktops and the older servers can't handle
> the frames above the 1500 bytes, of course, so the entire network is still
> limited to the small frame size.

> We could setup a small PC running something like FreeBSD to transparently
> fragment packets from one interface to another, but I'm wondering, if such
> devices are already available out there... Thanks!

any router will do. Fragmenting is part of ipv4


Have you done any measurment if you gain anything with jumbo frames ?

> -mi

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

phn@icke-reklam.ipsec.nu wrote in <cgnnac$2poh$1@nyheter.ipsec.se>:

> Mikhail Teterin <usenet@aldan.algebra.com> wrote:
>> Hello!
>
>> Our newer computers tend to come with NICs, that can handle big frame
>> sizes (at least 8 or 9 K, some even 15). We also have one 24-port switch,
>> that can handle 15K frames. But many desktops and the older servers can't
>> handle the frames above the 1500 bytes, of course, so the entire network
>> is still limited to the small frame size.

>> We could setup a small PC running something like FreeBSD to transparently
>> fragment packets from one interface to another, but I'm wondering, if
>> such devices are already available out there... Thanks!

> any router will do. Fragmenting is part of ipv4

That's the problem -- we don't want to split the network into subnets. Can't
we stay one layer below routers -- a fragmenting bridge (pardon my clumsy
terminology) of some sort, perhaps?

> Have you done any measurment if you gain anything with jumbo frames ?

No extensive studies to justify splitting into sub-networks. Only
observations, that our app-server talk to the db-servers a LOT.

Yours,

-mi
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

Mikhail Teterin <usenet@aldan.algebra.com> wrote:
> phn@icke-reklam.ipsec.nu wrote in <cgnnac$2poh$1@nyheter.ipsec.se>:

>> Mikhail Teterin <usenet@aldan.algebra.com> wrote:
>>> Hello!
>>
>>> Our newer computers tend to come with NICs, that can handle big frame
>>> sizes (at least 8 or 9 K, some even 15). We also have one 24-port switch,
>>> that can handle 15K frames. But many desktops and the older servers can't
>>> handle the frames above the 1500 bytes, of course, so the entire network
>>> is still limited to the small frame size.

>>> We could setup a small PC running something like FreeBSD to transparently
>>> fragment packets from one interface to another, but I'm wondering, if
>>> such devices are already available out there... Thanks!

>> any router will do. Fragmenting is part of ipv4

> That's the problem -- we don't want to split the network into subnets. Can't
> we stay one layer below routers -- a fragmenting bridge (pardon my clumsy
> terminology) of some sort, perhaps?

What's wrong with routing and deterministic network ?

>> Have you done any measurment if you gain anything with jumbo frames ?

> No extensive studies to justify splitting into sub-networks. Only
> observations, that our app-server talk to the db-servers a LOT.

I mean, have you done any measurment if jumbo-frames will give you
anything but trouble ?

For instance, if the majority part of your packets are < 1500 bytes
then enabling jumbos won't give much of a boost.

Don't use "features" just becouse some vendor says so. Use the
features that will give your application(s) a boost AND that
don't lock you into [vendor-dependence | scalability issues | maintanace
trouble ]


> Yours,

> -mi

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

phn@icke-reklam.ipsec.nu wrote in <ch59fq$2v5h$4@nyheter.ipsec.se>:

>> That's the problem -- we don't want to split the network into subnets.
>> Can't we stay one layer below routers -- a fragmenting bridge (pardon my
>> clumsy terminology) of some sort, perhaps?
>
> What's wrong with routing and deterministic network ?

It is a _change_ and this requires _work_ -- such as configuring routers,
modifying network settings on servers and DHCP-settings for clients.

>>> Have you done any measurment if you gain anything with jumbo frames ?
>
>> No extensive studies to justify splitting into sub-networks. Only
>> observations, that our app-server talk to the db-servers a LOT.
>
> I mean, have you done any measurment if jumbo-frames will give you
> anything but trouble?

I know, what you were asking, and I answered: NO, we HAVE NOT.

Now, are you aware of a bridge-type device, I'm asking about?

> For instance, if the majority part of your packets are < 1500 bytes
> then enabling jumbos won't give much of a boost.

I know, but conducting such study requires work, and work is expensive,
compared to the device, I hope exists. So we go with "guestimates": our
many applications use packet sizes of 4K to talk to Sybase servers. I
think, it is a good guess, that making the entire packet fit into a single
Ethernet frame can help performance. We also dump databases over NFS.

> Don't use "features" just becouse some vendor says so. Use the
> features that will give your application(s) a boost AND that
> don't lock you into [vendor-dependence | scalability issues | maintanace
> trouble ]

There is no vendor.

-mi
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <15198068.kmfYAppCL7@Misha>,
Mikhail Teterin <usenet@aldan.algebra.com> wrote:

> Hello!
>
> Our newer computers tend to come with NICs, that can handle big frame sizes
> (at least 8 or 9 K, some even 15). We also have one 24-port switch, that
> can handle 15K frames. But many desktops and the older servers can't handle
> the frames above the 1500 bytes, of course, so the entire network is still
> limited to the small frame size.
>
> We could setup a small PC running something like FreeBSD to transparently
> fragment packets from one interface to another, but I'm wondering, if such
> devices are already available out there... Thanks!
>
> -mi

It is not possible to transparently fragment at the Link Layer. Ethernet
(and most other LAN technologies) has no mechanism for fragmentation;
equally important, there would be no means for the receiving end station
to reassemble the fragments.

Some network layer protocols (but not all) include
fragmentation/reassembly capability, but these functions are notoriously
inefficient. Since the vast majority of packets do *not* require
fragmentation (one hopes), fragmentation/reassembly are generally
performed outside the "fast path" of the code; as a result, performance
suffers *significantly*. In addition, reassembly tends to be memory
intensive (since buffers must be retained until all fragments of a
packet have been received and reassembled).

In any case, fragmentation in practical networks can only be performed
in an IP-aware intermediate device (a router, or as another poster
alluded to, a "transparent router," such as were once popular for
FDDI-to-Ethernet connections). Even so, if the majority of packets are
going to be exchanged between a jumbo-enabled server and
non-jumbo-capable end stations (as you imply from your post), it would
be *much* more efficient to disable the jumbo frame capability on the
server, and let the packets stay intact throughout their journey. All
you would be doing is shifting the function from the server to the
intermediate device; the server can avoid invoking true IP fragmentation
by simply using the smaller frame size. This is why MTU Discovery was
developed; to allow end stations to use smaller packets rather than
force intermediate routers to perform fragmentation.

Furthermore, using an intermediate router would require that you divide
your network into subnetworks across the router ports; by definition, a
router only relays packets between IP subnets. You indicated that this
was undesirable from an administration/management perspective.

Bottom line--disable the jumbo frame capability, or use MTU Discovery
(which will effectively do the same thing, only automatically).

Patient: "Doctor, it hurts when I do this!"
Doctor: "Then don't do this."


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 395-1966 FAX

Send replies to: usenet at richseifert dot com
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

Long long ago, and far away, there were FDDI to Ethernet bridges (I'm
starting to feel like Grandpa here :) that "fragmented" IP datagrams
from the large MTU side (FDDI with a ~4500 byte MTU) to the small MTU
side (Ethernet).

However, my recollection (groups.google.com would be a good thing to
check) is that the devices didn't work all _that_ well. They were
doing one thing that "belonged" in the network (IP) layer, but did not
do all the things required of the network layer (such as generate the
PathMTU Discovery ICMP Datagram Too Big messages...)

Also, if much of your traffic is TCP, enabling Jumbo on your servers
isn't going to do much with traffic to the clients - the TCP
connection establishment will have the servers say some large value,
the clients the small value and the small value will be used anyway.
That will also happen with the router.

You would only get the JF TCP MSSes between two systems with
JumboFrame enabled.

That then ties-in with the queries about whether or not you've checked
that going to JF would buy you anything in the first place. How much
of your comms would be between JF-capable systems on a JF capable
switch? If there is not a _lot_ of 1460 byte MSS (1500 byte MTU)
traffic between those systems, and it is all smaller stuff of a few
hundred bytes, then JF won't buy you anything except perhaps the
occasional connectivity problem when the mythical bridge didn't behave
properly.

That means taking packet traces and/or generating some statistics from
the network and/or link-level stats available on your systems.

The other option is to use "large send" or what Linux 2.6 calls TSO.
This is something of a "poor man's" JF - the NIC knows just enough
(but no more) to offload segmentation work from TCP. TCP can then
pass large sends to the NIC (via IP and the driver of course...) and
the NIC then segments them into the standard sizes for transmission on
the medium.

I say "poor man's" because it only offloads the sending overhead - the
reciever still gets a stream of 1460 byte TCP segments. You also have
just as many ACK's with large send as you would have without it where
JF also cuts the number of ACKs per MB. ACK's don't do much on the
wire, but they do consume just about as much CPU in the host(s) as any
other segment (particularly if there is zero-copy in the host.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert <usenet-@-richseifert-dot-com.invalid> wrote:
> Bottom line--disable the jumbo frame capability, or use MTU Discovery
> (which will effectively do the same thing, only automatically).

Does PathMTU discovery even kick-in when the communicating ends are on
the same broadcast domain/IP subnet? And if they were in different IP
subnets, there would already be a router in place and presumeably a
separation of broadcast domains so no need for that evil, cheating JF
to regular frame device :).

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...