slightly [OT] - Jumbo Frames question

Hello

A quick Google search confused me rather than helped ... if a device can
have an MTU value set for it (a NAS box in this case), is that the same
as saying that the jumbo frame size will equal the MTU size?

If so, and I enable jumbo frame handling (knowing that the switch and
NIC are OK with jumbo frames on a Gb interface), can I assume that the
frame size can be increased by trial-and-error MTU-value
experimentation, until I get to the point whereby jumbo frame data rate
ceases to improve?

In article <(E-Mail Removed)>, DDS <(E-Mail Removed)> wrote:
>A quick Google search confused me rather than helped ... if a device can
>have an MTU value set for it (a NAS box in this case), is that the same
>as saying that the jumbo frame size will equal the MTU size?

The MTU is the maximum frame size. A jumbo frame is any frame larger
than the standard Ethernet MTU of 1514 bytes. If you configure the MTU
on a device to be larger than 1514 (or 1500 on the IP layer), then it
may send out jumbo frames, but it's unlikely that *every* frame will be
that size.

>If so, and I enable jumbo frame handling (knowing that the switch and
>NIC are OK with jumbo frames on a Gb interface), can I assume that the
>frame size can be increased by trial-and-error MTU-value
>experimentation, until I get to the point whereby jumbo frame data rate
>ceases to improve?

Yes, but it would be easier to just set it to the largest possible value
(often 9000) that is supported by your networking kit and leave it.

--
-- river. | Free Usenet: http://news.rt.uk.eu.org/
Non-Reciprocal Laws of Expectations: | PGP: 2B9CE6F2
Negative expectations yield negative results.
Positive expectations yield negative results.

> Yes, but it would be easier to just set it to the largest possible value
> (often 9000) that is supported by your networking kit and leave it.


Excellent help - thanks for the information and instruction.

Happy Christmas.

On Thu, 2011-12-22 at 11:03 +0000, River Tarnell wrote:
> >If so, and I enable jumbo frame handling (knowing that the switch and
> >NIC are OK with jumbo frames on a Gb interface), can I assume that the
> >frame size can be increased by trial-and-error MTU-value
> >experimentation, until I get to the point whereby jumbo frame data rate
> >ceases to improve?
>
> Yes, but it would be easier to just set it to the largest possible value
> (often 9000) that is supported by your networking kit and leave it.

Hm, really? Think about what such 'experimentation' would involve...

The MRU for each device on a network may be different: you might be able
to send a full 9kB frame to one host, but be limited to 1½kB to another
host — depending on the Ethernet hardware in use, the drivers, and the
operating system's network stack.

So this 'experimentation' would want to be done separately for each host
in the network. It would be a bit like normal path MTU discovery at the
IP layer... except of course that it's at the Ethernet level, rather
than IP.

The important difference there is that with IP you get *feedback* when
you send a packet that's too large, in the form of an ICMP message. But
Ethernet gives you no such indication. There's no way for the Ethernet
layer to *know* that a given packet was dropped because it caused a
'frame too large' exception at the receiving NIC. It'd be like trying to
do IP-level pMTU discovery when afflicted by one of these moronic
sysadmins who think it's clever to block ICMP.

And even if you *could* have a correctly-inferred per-destination MTU at
the Ethernet level, it would be painful to act on it. The destination
MAC address is found as the result of Neighbour Solicitation (for IPv6)
or ARP (for Legacy IP), often when the packet is already ready to be
*sent*... and after its size has been determined.

With IP-level pMTU discovery, you do end up storing the MTU to
individual hosts in the route cache, so that part might not be
*completely* unworkable because it can be propagated up after ARP/ND...
with a certain amount of complexity to handle the ARP/ND results
changing for a given IP destination. But in the absence of any reliable
way to make the inference in the first place, I can't imagine anyone
would ever implement this 'experimentation' of which you speak.

Whatever MTU you set on an interface, *all* devices on that physical
link must be able to receive packets of that size. Unless I'm severely
mistaken.

--
dwmw2

David Woodhouse wrote:
> On Thu, 2011-12-22 at 11:03 +0000, River Tarnell wrote:
>>> If so, and I enable jumbo frame handling (knowing that the switch and
>>> NIC are OK with jumbo frames on a Gb interface), can I assume that the
>>> frame size can be increased by trial-and-error MTU-value
>>> experimentation, until I get to the point whereby jumbo frame data rate
>>> ceases to improve?
>> Yes, but it would be easier to just set it to the largest possible value
>> (often 9000) that is supported by your networking kit and leave it.
>
> Hm, really? Think about what such 'experimentation' would involve...
>
> The MRU for each device on a network may be different: you might be able
> to send a full 9kB frame to one host, but be limited to 1½kB to another
> host — depending on the Ethernet hardware in use, the drivers, and the
> operating system's network stack.
>
> So this 'experimentation' would want to be done separately for each host
> in the network. It would be a bit like normal path MTU discovery at the
> IP layer... except of course that it's at the Ethernet level, rather
> than IP.
>
> The important difference there is that with IP you get *feedback* when
> you send a packet that's too large, in the form of an ICMP message. But
> Ethernet gives you no such indication. There's no way for the Ethernet
> layer to *know* that a given packet was dropped because it caused a
> 'frame too large' exception at the receiving NIC. It'd be like trying to
> do IP-level pMTU discovery when afflicted by one of these moronic
> sysadmins who think it's clever to block ICMP.
>
> And even if you *could* have a correctly-inferred per-destination MTU at
> the Ethernet level, it would be painful to act on it. The destination
> MAC address is found as the result of Neighbour Solicitation (for IPv6)
> or ARP (for Legacy IP), often when the packet is already ready to be
> *sent*... and after its size has been determined.
>
> With IP-level pMTU discovery, you do end up storing the MTU to
> individual hosts in the route cache, so that part might not be
> *completely* unworkable because it can be propagated up after ARP/ND...
> with a certain amount of complexity to handle the ARP/ND results
> changing for a given IP destination. But in the absence of any reliable
> way to make the inference in the first place, I can't imagine anyone
> would ever implement this 'experimentation' of which you speak.
>
> Whatever MTU you set on an interface, *all* devices on that physical
> link must be able to receive packets of that size. Unless I'm severely
> mistaken.
>
Dont confuse a frame with an MTU either.

The MUT is the biggest packet you will split the data into. The frame is
the amount of packets - or data within packets - you can send before
stopping and waiting for an ACK.

It should be set to the value such that the delay time in the network
approximates to the frame divided by the transfer speed.

so that e.g. with a fast but high latency satellite link you want it
very large, so you don't sit waiting for an ACK that's taking seconds to
come back to you - you keep on pumping on the assumption its all got
through.

Of course if it hasn't, the frame is the SIZE of the data you have to
retransmit...which is why in high packet loss networks large frames are
a complete disaster..huge amounts of duplicate data just fuck the thing
up even more.

In article <jd0h56$sh8$(E-Mail Removed)>,
The Natural Philosopher <(E-Mail Removed)> wrote:
>Dont confuse a frame with an MTU either.

>The MUT is the biggest packet you will split the data into. The frame is
>the amount of packets - or data within packets - you can send before
>stopping and waiting for an ACK.

No, a frame is a "packet" on an Ethernet network, i.e. the maximum frame
size is the maximum amount of data you can send at once.

You're thinking of the send / receive buffers, which control how much
data can be on the wire before an ACK is received (and as you say, a
network path which has high throughput, but also high latency, will need
a larger buffer size to operate efficiently). This is unrelated to
frame size / MTU -- whatever the MTU is, you still need the same size
buffers.

--
-- river. | Free Usenet: http://news.rt.uk.eu.org/
Non-Reciprocal Laws of Expectations: | PGP: 2B9CE6F2
Negative expectations yield negative results.
Positive expectations yield negative results.

On Fri, 2011-12-23 at 00:14 +0000, The Natural Philosopher wrote:
> Dont confuse a frame with an MTU either.
>
> The MUT is the biggest packet you will split the data into. The frame
> is the amount of packets - or data within packets - you can send
> before stopping and waiting for an ACK.

That is usually called the 'window'. A frame is a packet.

> Of course if it hasn't, the [window] is the SIZE of the data you have
> to retransmit...which is why in high packet loss networks large
> [windows] are a complete disaster..huge amounts of duplicate data just
> fuck the thing up even more.

Nah, that hasn't been true for TCP since SACK was invented in the
mid-1990s. You don't have to retransmit the whole window; only the
missing fra^H^H^Hpackets.

--
dwmw2

River Tarnell wrote:
> In article <jd0h56$sh8$(E-Mail Removed)>,
> The Natural Philosopher <(E-Mail Removed)> wrote:
>> Dont confuse a frame with an MTU either.
>
>> The MUT is the biggest packet you will split the data into. The frame is
>> the amount of packets - or data within packets - you can send before
>> stopping and waiting for an ACK.
>
> No, a frame is a "packet" on an Ethernet network, i.e. the maximum frame
> size is the maximum amount of data you can send at once.
>

Aplogies.. I was thinking of something else..


> You're thinking of the send / receive buffers, which control how much
> data can be on the wire before an ACK is received (and as you say, a
> network path which has high throughput, but also high latency, will need
> a larger buffer size to operate efficiently). This is unrelated to
> frame size / MTU -- whatever the MTU is, you still need the same size
> buffers.
>

Its not send/receive buffers per se..those are almost infinitely
extensible within reason..


...its TCP window size or something.

Often called frames..

On Fri, 23 Dec 2011 00:36:38 +0000, The Natural Philosopher churned:

> Its not send/receive buffers per se..those are almost infinitely
> extensible within reason..
>
>
> ..its TCP window size or something.
>
> Often called frames..

By you, perhaps, but to anyone who's got past 'the Ladybird book of
networking' perhaps not....

Nucking Futs wrote:
> On Fri, 23 Dec 2011 00:36:38 +0000, The Natural Philosopher churned:
>
>> Its not send/receive buffers per se..those are almost infinitely
>> extensible within reason..
>>
>>
>> ..its TCP window size or something.
>>
>> Often called frames..
>
> By you, perhaps, but to anyone who's got past 'the Ladybird book of
> networking' perhaps not....

Well tell that to wikipedia.