Maximum size of Ethernet frame
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||||||||||||||||||||||||||
|
Posted by Mark on November 11, 2004, 9:40 am
Please log in for more thread options restricted to 1500 bytes by the standard even though the length field is 2-bytes? (1500 is not even a multiple of 2!). thanks, Steve | |||||||||||||||||||||||||||||||||||||
|
Posted by Rich Seifert on November 11, 2004, 8:16 pm
Please log in for more thread options The 1500 byte payload limit was somewhat arbitrary. *Some* upper limit is needed for a number of reasons: -The longer the maximum frame allowed, the longer the maximum delay on a shared medium. All stations must wait for a frame-in-progress to complete before attempting their own transmission; longer frames means longer wait time. -Longer frames increases the probability that one or more bits in the frame will be received in error, necessitating retransmission of the frame. (In the extreme case, an infinitely-long frame is *guaranteed* to contain bit errors, ensuring that it would *never* be correctly received!) -A longer maximum frame increases the memory requirement for a NIC using a simple, fixed buffer design. This is the *real* reason for the 1500 byte limit; at the time we designed it (1979), buffer memory was much more expensive than it is now, and DMA controllers were too complex to be implemented in anything less than a full-custom chip. -- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX Send replies to: usenet at richseifert dot com | |||||||||||||||||||||||||||||||||||||
|
Posted by glen herrmannsfeldt on November 12, 2004, 12:34 pm
Please log in for more thread options Rich Seifert wrote:
(snip regarding ethernet 1500 byte limit) > The 1500 byte payload limit was somewhat arbitrary. *Some* upper limit
> is needed for a number of reasons: > -The longer the maximum frame allowed, the longer the maximum delay on a
> shared medium. All stations must wait for a frame-in-progress to > complete before attempting their own transmission; longer frames means > longer wait time. It would seem, then, that 1024 or 2048 would have been more convenient for some systems, but then that doesn't leave any space for headers of whatever protocol is in use. Also, assuming hardware buffers made of commercial SRAM, which tend to be powers of two, there is controller overhead. A 2048 byte payload would require a 4096 byte, minimum, RAM buffer. 1500 is convenient in allowing 1024 bytes, plus some layers of other headers. -- glen | |||||||||||||||||||||||||||||||||||||
|
Posted by Michelot on November 12, 2004, 2:05 pm
Please log in for more thread options Bonjour Rich,
Interresting reply, I just comment that. > -Longer frames increases the probability that one or more bits in the
> frame will be received in error, necessitating retransmission of the > frame. (In the extreme case, an infinitely-long frame is *guaranteed* to > contain bit errors, ensuring that it would *never* be correctly > received!) There is no difference between one error in the payload of one Ethernet frame, or one error in the payloads of 50 successive Ethernet frames carrying the same application layer message. At the application layer, the reassembled message could be discarded. The problem with the global Ethernet stack (SNAP > LLC > MAC > xxBasex) is
that we dont't have a complete adaptation layer. The Ethernet frame limit is
reported to the 3-layer because there is no way to detect a floating 3-layer header in the Ethernet payload (each SNAP payload always begins by a level-3 header). Regards, Michelot | |||||||||||||||||||||||||||||||||||||
|
Posted by Rich Seifert on November 12, 2004, 11:02 am
Please log in for more thread options
>
> There is no difference between one error in the payload of one Ethernet > frame, or one error in the payloads of 50 successive Ethernet frames > carrying the same application layer message. At the application layer, the > reassembled message could be discarded. > There is a BIG difference. Let's say that I want to send 1 million bytes of application data. If I send it as 500 blocks of 2K bytes each, and there is an error in one of the frames, a single 2K block must be retransmitted (typically, at the Transport layer). If instead I send the data as a single message of 1 million bytes and there is an error in the frame (which I agree has the same probability of containing an error as the 500 blocks of 2K bytes), then I must retransmit the ENTIRE 1 million bytes over again. That's a severe penalty for a single bit error. > The problem with the global Ethernet stack (SNAP > LLC > MAC > xxBasex) is
> that we dont't have a complete adaptation layer. The Ethernet frame limit is > reported to the 3-layer because there is no way to detect a floating 3-layer > header in the Ethernet payload (each SNAP payload always begins by a level-3 > header). > I am not sure what you are talking about here. SNAP and LLC are rarely used, particularly not in a TCP/IP context. (They are used for things like AppleTalk, and NetBIOS/NetBEUI, but these are minor players today, relative to TCP/IP.) In the more typica, IP-over-Ethernet scheme, we use Type encapsulation, and the IP header appears immediately following the Protocol Type field; it does not "float". -- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX Send replies to: usenet at richseifert dot com | |||||||||||||||||||||||||||||||||||||
> restricted to 1500 bytes by the standard even though the length field
> is 2-bytes? (1500 is not even a multiple of 2!).
>