MTU for networking

Can somebody help? How is TCP/IP stack usually designed in OSes if
different physical
drivers with different physical maximal size of frames need to be
transferred? Does IP stack do any interrogation during startup
procedure to investigate how much is maximal length of the frame of
particular device - e.g. Ethernet, FDDI, WiFi? Thanks.

On 9/14/2011 12:19 PM, martinfnp@yahoo.com wrote:
> Can somebody help? How is TCP/IP stack usually designed in OSes if
> different physical
> drivers with different physical maximal size of frames need to be
> transferred? Does IP stack do any interrogation during startup
> procedure to investigate how much is maximal length of the frame of
> particular device - e.g. Ethernet, FDDI, WiFi? Thanks.

"That depends"...  :>

First, recall this is c.a.e -- so, often, the system/device need
not support a wide variety of networking "options", protocols,
media, etc.  One (or a couple) of *particular* NICs are supported
by the product... it's not like a desktop environment where you
have to tolerate *any* sort of network interface being plugged.

And, even within that constraint, a developer/product could
further constrain the buffer size(s) available.

Also, it depends on how high up the protocol stack you are
dealing with these buffers.  I.e., the higher up, the more
leeway you have to deal with "virtual" buffers instead of
*physical* ones.  OTOH, some network devices can treat a
list/chain of smaller buffers *as* a larger buffer (to
accommodate fragmentation).

So, you have to look at the needs of *your* application/device
and the capabilities of your current/future hardware and
decide how flexible you want the protocol stack and drivers
to be.

E.g., if you are running an ethernet, you could opt for
1500 byte buffers and accept whatever "waste" comes with
that decision.  OTOH, if you are just expecting to deal
with (e.g.) ICMP messages, you might opt for smaller
buffers knowing the larger size isn't needed.  If you *know*
the constraints that will be imposed (or, that you *can* impose)
on the traffic, you can tweek the entire protocol stack to
exploit that knowledge -- at the risk of requiring a rewrite
if any of those assumptions change.

HTH

On Sep 14, 9:35=A0pm, Don Y <nowh...@here.com> wrote:
> On 9/14/2011 12:19 PM, martin...@yahoo.com wrote:
>
> > Can somebody help? How is TCP/IP stack usually designed in OSes if
> > different physical
> > drivers with different physical maximal size of frames need to be
> > transferred? Does IP stack do any interrogation during startup
> > procedure to investigate how much is maximal length of the frame of
> > particular device - e.g. Ethernet, FDDI, WiFi? Thanks.
>
> "That depends"... =A0:>
>
> First, recall this is c.a.e -- so, often, the system/device need
> not support a wide variety of networking "options", protocols,
> media, etc. =A0One (or a couple) of *particular* NICs are supported
> by the product... it's not like a desktop environment where you
> have to tolerate *any* sort of network interface being plugged.
>
> And, even within that constraint, a developer/product could
> further constrain the buffer size(s) available.
>
> Also, it depends on how high up the protocol stack you are
> dealing with these buffers. =A0I.e., the higher up, the more
> leeway you have to deal with "virtual" buffers instead of
> *physical* ones. =A0OTOH, some network devices can treat a
> list/chain of smaller buffers *as* a larger buffer (to
> accommodate fragmentation).
>
> So, you have to look at the needs of *your* application/device
> and the capabilities of your current/future hardware and
> decide how flexible you want the protocol stack and drivers
> to be.
>
> E.g., if you are running an ethernet, you could opt for
> 1500 byte buffers and accept whatever "waste" comes with
> that decision. =A0OTOH, if you are just expecting to deal
> with (e.g.) ICMP messages, you might opt for smaller
> buffers knowing the larger size isn't needed. =A0If you *know*
> the constraints that will be imposed (or, that you *can* impose)
> on the traffic, you can tweek the entire protocol stack to
> exploit that knowledge -- at the risk of requiring a rewrite
> if any of those assumptions change.
>
> HTH

Thank you. But I'm specially asking about the relationship between IP
stack and physical device driver like Ethernet. If I look at the
content of the Ethernet frame there is no indication of fragmentation.
But it's definitely in IP part of the frame. If there is Ethernet
only, then IP stack can be hardcoded for MTU as you mentioned. But
typically you can have - Ethernet, USB (Ethernet via USB class) and
WiFi. In that case I would assume IP stack needs to be designed the
way it "learns" MTU size during the startup - either as hardcoded
value for each particular interface or even stored configurable value
in NAND or NOR. Or am I wrong?

martinfnp@yahoo.com wrote:
> Can somebody help? How is TCP/IP stack usually designed in OSes if
> different physical
> drivers with different physical maximal size of frames need to be
> transferred? Does IP stack do any interrogation during startup
> procedure to investigate how much is maximal length of the frame of
> particular device - e.g. Ethernet, FDDI, WiFi? Thanks.

IP stacks usually have a block of state per interface ( each
physical driver probably maps to an interface, even if the
media is shared, which is seldom the case  ) and each
block will have ifEntry.ifMtu as a parameter settable by
said driver.

http://rfc-ref.org/RFC-TEXTS/2863/chapter6.html#d4e448321

--
Les Cargill

On Sep 14, 9:57=A0pm, Les Cargill <lcargil...@comcast.com> wrote:
> martin...@yahoo.com wrote:
> > Can somebody help? How is TCP/IP stack usually designed in OSes if
> > different physical
> > drivers with different physical maximal size of frames need to be
> > transferred? Does IP stack do any interrogation during startup
> > procedure to investigate how much is maximal length of the frame of
> > particular device - e.g. Ethernet, FDDI, WiFi? Thanks.
>
> IP stacks usually have a block of state per interface ( each
> physical driver probably maps to an interface, even if the
> media is shared, which is seldom the case =A0) and each
> block will have ifEntry.ifMtu as a parameter settable by
> said driver.
>
> http://rfc-ref.org/RFC-TEXTS/2863/chapter6.html#d4e448321
>
> --
> Les Cargill

Thx Les. Basically you say IP stack starts fragmentation of the frame
depending on that parameter?

martinfnp@yahoo.com wrote:
> On Sep 14, 9:57 pm, Les Cargill<lcargil...@comcast.com>  wrote:
>> martin...@yahoo.com wrote:
>>> Can somebody help? How is TCP/IP stack usually designed in OSes if
>>> different physical
>>> drivers with different physical maximal size of frames need to be
>>> transferred? Does IP stack do any interrogation during startup
>>> procedure to investigate how much is maximal length of the frame of
>>> particular device - e.g. Ethernet, FDDI, WiFi? Thanks.
>>
>> IP stacks usually have a block of state per interface ( each
>> physical driver probably maps to an interface, even if the
>> media is shared, which is seldom the case  ) and each
>> block will have ifEntry.ifMtu as a parameter settable by
>> said driver.
>>
>> http://rfc-ref.org/RFC-TEXTS/2863/chapter6.html#d4e448321
>>
>> --
>> Les Cargill
>
> Thx Les. Basically you say IP stack starts fragmentation of the frame
> depending on that parameter?


Start here:
http://en.wikipedia.org/wiki/IP_fragmentation
and here:
http://penguin.dcs.bbk.ac.uk/academic/networks/network-layer/fragmentation/index.php

Homogenous MTU is better if you can do it.

--
Les Cargill

On Wed, 14 Sep 2011 12:19:15 -0700, martinfnp@yahoo.com wrote:

> Can somebody help? How is TCP/IP stack usually designed in OSes if
> different physical
> drivers with different physical maximal size of frames need to be
> transferred? Does IP stack do any interrogation during startup
> procedure to investigate how much is maximal length of the frame of
> particular device - e.g. Ethernet, FDDI, WiFi? Thanks.

The kernel maintains a table of devices along with their parameters. The
driver will provide default parameters when a device is initialised. The
parameters can be modified (e.g. by ifconfig) within the bounds of what
the hardware and/or medium permits. E.g. ethernet is typically[1] limited
to a 1500-byte MTU, while SLIP/PPP links don't have any inherent limit.

[1] Larger values may be possible ("jumbo frames"), but all devices on a
segment should use the same value. This tends to limit the use of jumbo
frames to specialised networks.

The IP layer will check the device's MTU for each packet which is routed
through a device, and fragment the packet if it is larger than the MTU (or
reject it with an ICMP fragmentation-needed error if the don't-fragment
flag is set, which is usually the case for TCP).

Applications which adjust packet sizes according to the MTU need to
remember that the routing tables (and thus the device through which
packets are routed) can change dynamically, as can the MTU of a given
device.

On 9/14/2011 12:45 PM, martinfnp@yahoo.com wrote:

> Thank you. But I'm specially asking about the relationship between IP
> stack and physical device driver like Ethernet. If I look at the
> content of the Ethernet frame there is no indication of fragmentation.
> But it's definitely in IP part of the frame. If there is Ethernet
> only, then IP stack can be hardcoded for MTU as you mentioned. But
> typically you can have - Ethernet, USB (Ethernet via USB class) and
> WiFi. In that case I would assume IP stack needs to be designed the
> way it "learns" MTU size during the startup - either as hardcoded
> value for each particular interface or even stored configurable value
> in NAND or NOR. Or am I wrong?

If several different media/protocols are intended to be supported
by the same stack, then registering an interface determines the
size buffers that it will need.  The mechanics of how this is
done are up to the stack -- the device initialization routine can
be responsible for building a buffer pool that it draws on and
passes to the network stack; or, the device can *tell* the
network stack what it wants/needs and the network stack can
then decide *if* it can provide those resources to the device
(i.e., the stack can "lie" and give the device bigger buffers than
it actually needs); etc.  (e.g., some devices have the buffer
memory *in* the NIC itself)

As I said, some devices are smart enough to manage their own
memory needs.  The *silicon* talks directly to memory and can
"traverse" a chain of buffers so that the host need not provide
*large* buffers (of which only part may be used in any given
transaction).  The driver then has to know how to interpret these
"filled" (in the case of Rx) buffers AS IF they were a larger
contiguous buffer.  (similar responsibilities exist on the Tx side)