Maximum size of Ethernet frame

I am wondering why was the maximum size of ethernet data payload 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

Reply to
Mark
Loading thread data ...

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

Reply to
Rich Seifert

Beyond 1500 (actually 1518 IIRC), it is no longer a length field. If 1536 or greater, it's a type field. Not sure, if in between.

Reply to
James Knott

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.

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

Reply to
Rich Seifert

(snip regarding ethernet 1500 byte limit)

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

Reply to
glen herrmannsfeldt

I thought TCP sliding window acknowledged the last point of contiguous successful transmission, so any retransmission could start from that point. If only on or a few packets were lost, as soon as they're received correctly, the acks could jump to the end of the sucessfully received data.

i.e. If only packet 6 of 10 were lost, the acks would initially show 5, then as soon as 6 is sucessfully received, the ack could jump to show all up to 10 were received correctly.

Reply to
James Knott

I am quite familiar with RFC 1042. What I am saying is, on Ethernet, we don't use it. The standards *allow* it, but in practice it is not done. RFC 1042 was developed to allow the use of Ethernet-style "type" fields on systems that do not directly support it (e.g., IEEE 802.5 Token Ring).

"In theory, theory and practice are the same. In practice, they are not."

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

Reply to
Rich Seifert

Bonjour Rich,

Interresting reply, I just comment that.

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

Reply to
Michelot

I think what Michelot is saying does not really change whether you use type or length formats. I think he's saying that when a network layer protocol is layered over Ethernet (or by the way any other IEEE 802.x LANs or FDDI), the beginning of the network layer packet must occur immediately following the Ethernet overhead. Unlike, for example, SONET, where the next upper layer payload can begin anywhere is the SONET frame and can end anywhere in that same frame or any subsequent frame.

But this is because Ethernet and other 802 LANs are not meant to provide an isochronous train of frames, as SONET does. Link layer transfers are asynchronous in IEEE 802 LANs. So an Ethernet frame is only created when there's a network layer packet ready to go.

Even so, it still helps, in slower links, to keep the network layer packets somewhat short, to more quickly detect and recover from corrupted packets. Also helps in reducing latency in live media streams. This is true even if the IP or other layer 3 packets are sent over a slow version of SONET.

Bert

Reply to
Albert Manfredi

Bonjour James,

I agree with you in the case of TCP protocol and lost IP datagrams.

Just a point. You can say also "as soon as a segment including the data of the initial 6 (it will be perhaps initial 6 and 7 and part of 8, in accordance with the MSS length) is successfully received, the receiver extracts its missing part and acknowledges up to initial 10". The retransmitted segment could be with a size different from the primitive one: the buffer has more data. We suppose not to be limited by the window.

I will also agree with you in the case of TCP protocol and wrong checksum. You remind me that the TCP checksum indeed covers all the TCP segment added with IP elements (IP addresses, protocol number, datagram length). And the case of wrong checksum is similar to the case of lost datagram(s).

But we can have an application that simply uses UDP protocol. The UDP datagram length is not restricted by the MSS parameter. So we can have e.g. a UDP payload of 65527 bytes. At the layer 3 the 65535-byte SDU gives 45 IP fragments. Each IP datagram except the last one has a payload of 1472 bytes that gives a MAC payload of 1500 bytes.

So, an application block or message of theoretically 65527 bytes can be carried in 45 successive Ethernet frames. It was that I wanted to say.

Regards, Michelot

Reply to
Michelot

Yes, this can be done, but it's not a good idea.

The IP layer will fragment packets that exceed the MTU (maximum transmission unit) of the link layer. Since TCP figures out its own MTU, the IP fragmentation feature would normally be applied only to UDP.

But then at the destination side, the fragments have to be recombined to reform the original layer 3 packet. If one of the fragments is corrupted, all those other 44 fragments will have to be discarded.

If the transfer is streaming media using UDP/IP, this means that what might have been a small glitch in the video or audio now becomes a big glitch.

If the transfer is a periodic series data updates, then you'll lose a lot of good information when just one of 45 frames was corrupted. A better idea is to design UDP datagrams that fit within the MTU of the link layer, and organize the data you want to send in logical sets that can fit within the MTU. That way, you can still make use of the good packets received.

Bert

Reply to
Albert Manfredi

Bonsoir Rich,

See please my reply to James. Today, many different applications exist and they don't segment necessarily in small data blocks. When 2 computers communicate on the same LAN, UDP using is simpler and quicker than TCP, and I think the BER is better than 10-9. So, we have one error per 1250 million bytes, around one error per 850 000 Ethernet frames. On a path of 17 500 km, the problem would be different.

You can see RFC1042 (SNAP encapsulation) that obsoletes RFC948 (without SNAP).

Yes also, and it's not the case in ATM, owing to AAL (but we have redundancy of course).

Regards, Michelot

Reply to
Michelot

Rich,

I'm just going to see 2 old Ethereal files, and effectively, it's of type fields. Four years ago, I worked on the Alcatel LMDS product (WLL) and I got used to see LLC/SNAP for the commissioning through an Ethernet link. My opinion of thinking that it was all over like that was consolidated by this RFC1042.

In we cannot completely trust standards, where are we going...?

Regards, Michelot

Reply to
Michelot

Bonsoir Alfred,

Ok

Yes, and we have in mind that this discarding is at the layer 4, because IP checksum is only for the header. So, you're right.

Terrible if it occurs during a beautiful girl picture! We can see that in ATM with AAL-5: when a cell has to be discarded, due to a queue congestion, the lose is extended to the AAL-5 end frame (PPD mechanism) or to the complete next AAL-5 frame (EPD).

Yes, it depends on the application service. I believe that it is not UDP that fit for the MTU or MSS, but this control is done by its clients: either the transport sub-layer RTP or directly the application layer.

Regards, Michelot

Reply to
Michelot

There is a common use of LLC/SNAP, but for the ATM encapsulation.

With ADSL, some operators here are using LLC/SNAP encapsulation. It is done by using RFC2684 bridge:

(1) in the LLC encapsulation structure: IP > LLC/SNAP with OUI=0x00-00-00 >

MAC > LLC/SNAP with OUI=0x00-80-C2 > AAL-5 (2) or in the VCC multiplexing structure: without the last LLC/SNAP.

Regards, Michelot

Reply to
Michelot

I saw this post disappeared from the thread. So I post it again.

========

Rich,

I'm just going to see 2 old Ethereal files, and effectively, it's of type fields. Four years ago, I worked on the Alcatel LMDS product (WLL) and I got used to see LLC/SNAP for the commissioning through an Ethernet link. My opinion of thinking that it was all over like that was consolidated by this RFC1042.

If we cannot completely trust standards, where are we going...?

Regards, Michelot

Reply to
Michelot

Read what he said, "On Ethernet". ADSL is not Ethernet. You might want to look up Rich's posting history before you argue with him. While it's possible for Rich to be wrong, if he tells you something about Ethernet that is different from what you believe it's a good idea to examine that belief very carefully before you go on.

Reply to
J. Clarke

Bonjour James,

Sorry, understand the context: it's ADSL technology and not ADSL physical layer. And some ADSL technologies carry LLC/MAC frames standardized in IEEE

802.3. Perhaps, you make a confusion, Ethernet is not only the physical layer like 10Base-T or 100Base-FX. The Ethernet layer 2 can be encapsulated in other protocols, like ATM or GFP.

Are you convinced, or do you need other developments ?

My objective is understanding, helping sometimes the participants, trying to progress myself and, perhaps, other persons. As you can see, English is not my native language, I do that with my words. And, sorry for your misenterpretation, it's not a competitive sport with a winner and a looser.

Thanks for your statement. Regards, Michelot

Reply to
Michelot

I udnerstand the reasons for having to define a maximum size ethernet frame (as we do for minimum size, which actually doesnt make sense now, when Ethernet is no more CSMA/CD). But I was curious to know why

1500 ? Well it was arbitrary then probably thats it!

thanks Mark

Reply to
Mark

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.