A Broadband and ADSL forum. BroadbanterBanter

Welcome to BroadbanterBanter.

You are currently viewing as a guest which gives you limited access to view most discussions and other FREE features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today.

Go Back   Home » BroadbanterBanter forum » Newsgroup Discussions » uk.telecom.broadband (UK broadband)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

uk.telecom.broadband (UK broadband) (uk.telecom.broadband) Discussion of broadband services, technology and equipment as provided in the UK. Discussions of specific services based on ADSL, cable modems or other broadband technology are also on-topic. Advertising is not allowed.

slightly [OT] - Jumbo Frames question



 
 
Thread Tools Display Modes
  #1  
Old December 22nd 11, 09:51 AM posted to uk.telecom.broadband
DDS
external usenet poster
 
Posts: 17
Default 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?

  #2  
Old December 22nd 11, 11:03 AM posted to uk.telecom.broadband
River Tarnell
external usenet poster
 
Posts: 28
Default slightly [OT] - Jumbo Frames question

In article , DDS 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.
  #3  
Old December 22nd 11, 12:50 PM posted to uk.telecom.broadband
DDS
external usenet poster
 
Posts: 17
Default slightly [OT] - Jumbo Frames question

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.


  #4  
Old December 22nd 11, 11:35 PM posted to uk.telecom.broadband
David Woodhouse
external usenet poster
 
Posts: 64
Default slightly [OT] - Jumbo Frames question

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 1kB 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

  #5  
Old December 23rd 11, 12:14 AM posted to uk.telecom.broadband
The Natural Philosopher
external usenet poster
 
Posts: 2,728
Default slightly [OT] - Jumbo Frames question

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 1kB 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 **** the thing
up even more.





  #6  
Old December 23rd 11, 12:22 AM posted to uk.telecom.broadband
River Tarnell
external usenet poster
 
Posts: 28
Default slightly [OT] - Jumbo Frames question

In article ,
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.


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.
  #7  
Old December 23rd 11, 12:25 AM posted to uk.telecom.broadband
David Woodhouse
external usenet poster
 
Posts: 64
Default slightly [OT] - Jumbo Frames question

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
**** 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

  #8  
Old December 23rd 11, 12:36 AM posted to uk.telecom.broadband
The Natural Philosopher
external usenet poster
 
Posts: 2,728
Default slightly [OT] - Jumbo Frames question

River Tarnell wrote:
In article ,
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.


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..

  #9  
Old December 23rd 11, 02:32 PM posted to uk.telecom.broadband
Nucking Futs
external usenet poster
 
Posts: 11
Default slightly [OT] - Jumbo Frames question

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....
  #10  
Old December 23rd 11, 02:35 PM posted to uk.telecom.broadband
The Natural Philosopher
external usenet poster
 
Posts: 2,728
Default slightly [OT] - Jumbo Frames question

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.

 




Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Slightly off topic NTL streaming video question ted_radioham uk.telecom.broadband (UK broadband) 0 September 7th 04 05:35 PM
Slightly OT - Port 25? Heel uk.telecom.broadband (UK broadband) 4 January 24th 04 06:48 AM
Slightly OT Robin Goodfellow uk.comp.home-networking (UK home networking) 0 September 5th 03 03:29 AM
Slightly OT Iain Hallam uk.comp.home-networking (UK home networking) 0 September 5th 03 01:30 AM
Slightly OT - A networking question for the gurus out there Craig Henry uk.telecom.broadband (UK broadband) 3 July 28th 03 11:38 AM


All times are GMT +1. The time now is 09:55 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.Content Relevant URLs by vBSEO 2.4.0
Copyright 2004-2019 BroadbanterBanter.
The comments are property of their posters.