ethernet hardware question

[Sin]

Well at my slow pentium 166 there is a difference... that firewall needs
to

check more headers I guess
that slows it down quite a lot, like 10 times slower.

Ummm I don't know where the firewall stands in the whole process but you
might be right. Does it check the 64K datagram or does it check the real
outgoing packets?

So far my testing has shown that losing a fragment does not happen often...
which is remarkable

Indeed but there are scenarios where this will be different. UDP is fragile,
espicially if you try to send large amounts of data using it.

Yes indeed... I wonder what would happen if I switch to the ip layer...

Would routers still prefer ip/tcp... ?

( By examing the ip protocol field. )

TCP stream is by far better than UDP if you want to have a reliable comm.
channel. It performs throttling, error correction, is friendly to other
traffic, etc...

Alex.

 

[mchiper]

In comp.os.ms-windows.networking.tcp-ip, Msg ID: <[email protected]>

I thought the context was a full duplex 100 meg Ethernet between
two workstations with a UTP crossover cable.

In that environment there is no back off and try again logic.
There are no collisions. The sender just sends. If both ends want to
send at the same time they are free to do so. If one end cannot
receive at the same time that it is sending then that end is broken.

So explaining Collisions and full duplex in the same environment
some how adds to the knowledge base?

Apologies if I have failed to monitor changing context.

What "context" where you monitoring?

 

[Vernon Schryver]

The standard ethernet MTU is 1500 bytes
...

Yes, but as I said, PPPoE reduces that 1500 byte MTU by something like
8 bytes. (I've forgotten the exact value.) Then there are the effects
of tunnels that can reduce the effective MTU byte by more than 40 bytes.
Then there is perfectly legal but now rare 802.3 encapsulation that
also reduces the effective MTU below 1500 even on a LAN.

If you want to completely avoid fragmentation, you'd best stick to
512. If you want to avoid fragmentation in practice today, 1024
is a lot smarter than the 1472 implied by the naive and simplistic
observation that the DIX Ethernet MTU is 1500.


Vernon Schryver (e-mail address removed)

 

[Skybuck Flying]

The round trip time of the slower host, but this of course can be
increased a lot depending on the processing needed on that packet.
What I'm trying to say is it makes a huge difference if you simply
send the packet and the remote host can either trash it or is fast
enough to completly process it before the next one arrives. With an
ongoing sustained stream of packets it's obvious that there will be
lost packets if the receiving host can't keep up with processing, but
otherwise would be fast enough on the ethernet level alone.

TCP does a lot of optimisations (congestion control) to actually
minimize packet loss (and hence retransmits) as much as possible.
Another thing to mention is that UDP packets of > 512 Bytes are non
standard. So, if what you intend to do should be useable in a just a
little wider area I think you should considder switching to TCP.

Currently I use 548 udp packets. ( in total 576 bytes )

576 is max ip packet size. 20 bytes for ip header and 8 bytes for udp
header.

Leaves 548 bytes for udp data.

I know an ip header can be 60 bytes max...

So 576 - 60 = 516 - 8 = 508 bytes max for udp.

In what case/scenerio can an ip header be 60 bytes ?!

 

[Skybuck Flying]

Currently I use 548 udp packets. ( in total 576 bytes )

576 is max ip packet size. 20 bytes for ip header and 8 bytes for udp
header.

Leaves 548 bytes for udp data.

I know an ip header can be 60 bytes max...

So 576 - 60 = 516 - 8 = 508 bytes max for udp.

In what case/scenerio can an ip header be 60 bytes ?!

Mobile networks might add extra ip options for routing.

Also this RFC mentions some options:

http://www.spacerobots.org/dennis/RFC/rfc791.txt

Having an app with a flexible data size is a plus

 

[shope]

Yes, but as I said, PPPoE reduces that 1500 byte MTU by something like
8 bytes. (I've forgotten the exact value.) Then there are the effects
of tunnels that can reduce the effective MTU byte by more than 40 bytes.
Then there is perfectly legal but now rare 802.3 encapsulation that
also reduces the effective MTU below 1500 even on a LAN.

If you want to completely avoid fragmentation, you'd best stick to
512.

512 or even 1500 is not good enough if you really need as high a performance
as possible (e.g. some online video editing systems, which dont like packets
smaller than 9kbytes)

If you want to avoid fragmentation in practice today, 1024

is a lot smarter than the 1472 implied by the naive and simplistic
observation that the DIX Ethernet MTU is 1500.

The "official way" that a lot of IP stacks use to find the optimal MTU is to
kick off MTU discovery.

this should find the maximum size IP packet that can be used over a given
path to given destination IP address (but the path might vary, so the packet
size could as well).

so what you really need is a way to ask the IP stack to find that, and then
report it to any application that really cares.

my experience has been that some IP stacks seem to do fragmentation
efficiently without too much fuss - stacks that support NFS have done this
for a long time.

So, as long as the loss rate for packets is low enough that sending say an
8.5k NFS frame has a reasonable chance that all frames arrive you should be
able to ignore the issue.

However, that assumes that there is some error recovery and pacing to keep
the loss rate in bounds....

 

[Guillaume Filion]

Hello,

"UDP packets of > 512 Bytes are non standard", you say.

Is this limit defined by an RFC or by practices ? Put in another way: what
would happen if an application exceeds this size ? (Sorry if this is silly,
I'm new to UDP

The rfc states that an implementation of UDP must accept datagrams of
576 (512+64) bytes. Anything more than that is not garanteed to be
supported.

I remember it well, since I had a 2 hours discussion about this last
year...

------
Picking the correct datagram size to use when sending data
is a complex topic [IP:9].
(a) In general, no host is required to accept an IP
datagram larger than 576 bytes (including header and
data), so a host must not send a larger datagram
without explicit knowledge or prior arrangement with
the destination host. Thus, MMS_S is only an upper
bound on the datagram size that a transport protocol
may send; even when MMS_S exceeds 556, the transport
layer must limit its messages to 556 bytes in the
absence of other knowledge about the destination
host.
--- ref: RFC1122 (http://www.faqs.org/rfcs/rfc1122.html)

My recommendation is to switch to TCP, it's so easier to use.

GFK's