RE: Strange public traceroutes return private RFC1918 addresses

And why 4470 for POS? Did everyone borrow a vendor's FDDI-like default
or is there a technical reason? PPP seems able to use 64k packets (as
can the frame-based version of GFP, incidentally, POS's likely
replacement).

According to this URL
http://www.columbia.edu/acis/networks/advanced/jumbo/jumbo.html
which you have seen before, the number of CRC bits in the protocol
header limits the number of bytes you can practically use for the
MTU. I expect that we won't go beyond 9000 byte MTUs for a long
time.

The 4470 for POS probably comes from Token Ring originally. In the
original 4 Mbps token ring a device was allowed to hold the token
for 9.1 ms which was enough time to transmit 4550 octets. This timing
was probably adopted by FDDI which borrowed a lot from the token
ring design. No doubt, the designers of POS were also influenced by
token ring and just chose the same size.

--Michael Dillon

How does a 50Mbyte MTU sound like?

http://www.psc.edu/~mathis/MTU/

~Hani Mustafa

Hani Mustafa <hani.mustafa@noorgroup.net> writes:

How does a 50Mbyte MTU sound like?

http://www.psc.edu/~mathis/MTU/

Sounds like a 10 terabyte packet buffer per interface in the router to
me. Sure will be spiffy to have a nice fine granularity of 50 megs
per packet for TCP backoff - handy thing that ever since rfc1323 you
can have 32-bit window sizes, or were these guys proposing dispensing
with the window altogether since 99.9999% of the time the data you
have to send will be under 50 megs? I'll channel Randy for a moment
and encourage my competitors to do this... on their *own* networks,
please.

                                        ---Rob

Excessive. The trouble is that you get to throw away much more data for a single bit error and also that the difference between the average packet size and the maximum would be huge, so any statically allocated buffers would essentially be a waste of memory most of the time.

Ok, I know that this is getting away from the original thread, but I've always wondered this...

Why is the MTU on Ethernet 1500 bytes? I have looked through various docs (eg IEEE Std 802.x) and can find where maxUntaggedFrameSize is listed as 1518 octets, but there is no mention of why this was chosen. I know where the minimum frame size comes from (CSMA/CD and propagation times, etc), but the maximum frame size number sounds fairly arbitrary.

-- Warren.

Why is the MTU on Ethernet 1500 bytes? I have looked through various
docs (eg IEEE Std 802.x) and can find where maxUntaggedFrameSize is
listed as 1518 octets, but there is no mention of why this was chosen.
I know where the minimum frame size comes from (CSMA/CD and propagation
times, etc), but the maximum frame size number sounds fairly arbitrary.

I believe Rich Seifert once said (on comp.dcom.lans.ethernet) that the
cost of the necessary buffer memory for the first Ethernet cards was a
relevant factor.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Warren Kumari wrote:

Ok, I know that this is getting away from the original thread, but I've
always wondered this...

Why is the MTU on Ethernet 1500 bytes? I have looked through various
docs (eg IEEE Std 802.x) and can find where maxUntaggedFrameSize is
listed as 1518 octets, but there is no mention of why this was chosen.
I know where the minimum frame size comes from (CSMA/CD and propagation
times, etc), but the maximum frame size number sounds fairly arbitrary.

Because that was a conveniently large amount of very pricey memory
availble at the time?

Because that was the amount that could be blatted down a 500 meter
hose and get the "CD" part to work at some common clock rate?