determination of length of packet............

If using the "length" format, those two length bytes indicate the frame length in bytes.

If using the "type" format, the source side, having computed and transitted the CRC, will stop transmitting data. So the destination side will detect that no more data bytes are arriving, and that's how the destination side knows.

In ATM, switches sync up on cell boundaries by looking for repeated cases in which a sequence of four bytes is followed by the 8-bit CRC of those four bytes. If this happens a few times in a row, you're confident that you've locked onto the cell boundary. But this is readily doable, and safe, only because the cell size and cell headers are fixed in length.

I suppose Ethernet could be made to assume that any 4-byte sequence which is the CRC of the previous bytes, starting with the MAC DA (whose location is known because it follows the preamble and frame start sequence), would mark the end of that frame. But wouldn't that possibly trunkate frames?

Bert

The Length field indicates the number of the *valid payload* bytes within the Data field; it does *not* indicate the frame length. The frame length is determined as the number of bytes received between the Start-of-Frame delimiter and the End-of-Frame delimiter (which, in 10 Mb/s Ethernet systems is not an express symbol, but implied by a lack of bytes received after the FCS).

The Length field is thus used to distinguish payload from pad, rather than to determine the length of the frame (e.g., for deciding how much buffer space is required).

Yes, with a probability of (2^-32) * L, where L is the length of the frame in bytes, assuming a random distribution of values for the bytes in the payload.

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

So in the case of Type encoding how does the MAC determine what is pad? Does it just send the entire frame (with pad) to the client and let the client figure it out?

Thanks, Anoop

(someone wrote)

So for IP 1 in 2**32/L packets would fail, probably when IP found that the length was shorter than the IP header said it should be. Hopefully at least one header byte would be changed before retransmitting.

-- glen

The payload protocol must have a way to determine the length, usually with its own length field. Any protocol designed for ethernet will naturally have one. Otherwise, one would be added as part of the ethernet encapsulation.

-- glen

IP does not perform retransmission on detected errors. If TCP is in use, TCP would retransmit data as a result of the packet discard within IP. That retransmission will have a different "identifier" field inserted in the IP header (typically, a wraparound counter is used for this).

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

With Type encapsulation, there *is no pad*, at least from the perspective of the MAC; the client must submit no less than 46 bytes of payload for a frame. If any padding needs to be done, it must be done by the MAC client, which presumably then knows how to strip it away from the received frame.

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

I am that "someone," Glen. But, just to be clear here, this isn't a problem. Because that's not how end of frame is determined anyway. I was only musing out loud, comparing Ethernet's approach with a completely different scheme, ATM, in which the cell header length and the cell length itself are both fixed quantities.

(If the cell header length is fixed, and you find several consecutive examples where the 5th byte is the CRC of the previous four bytes, you have pretty good confidence that you're synched up to cell boundaries. But if the frame size is variable, as in Ethernet, you can't use this scheme without running into potential frame trunkation problems.)

But just for grins, if Ethernet did use such a scheme, and the receiving IP layer rejected the trunkated packet, I suppose it is possible that the retried TCP segment would be identical to the original one, no? E.g. if this is an FTP transfer, and each frame is max length?

Bert

(snip)

Yes, I snipped too far and didn't go back to add your name in. I might have wondered about this one before. Consider, though, that a noisy line might confuse the end of frame detection, and if the CRC matches the frame will be accepted. At gigabit speeds it doesn't take long to get 2**32 frames through.

I do remember when I was first learning about serial/RS232 data how it would find the frame with a continuous transmitting source, and then sometime later figuring out that the start/stop bit combination would allow it to sync. to the right frame fairly fast.

I didn't remember the field, but Rich says that there is a TCP field that will be different. Maybe not for UDP though.

-- glen

The TCP encapsulation would probably be identical in all respects. All IP packets include a "unique identifier" field, which is used to filter duplicates (among other things). Typically, this is implemented as a wraparound counter. Thus, when TCP submits the identical retransmitted segment, IP will prepend a different unique ID in the IP header, thus making the frame and both its IP checksum and Ethernet CRC value different.

The same would be true for UDP-based applications, since it is IP that is inserting the unique identifier.

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

I was under the impression that the Identification field was used only for identifying fragments that belong to the same packet. It isn't used for filtering duplicates; that is a function to be handled by the transport protocols (TCP/UDP) - since UDP doesn't do retransmissions, the duplicate packets would be passed up to the app, while in the case of TCP, a duplicate packet's sequence number would fall out of the current acceptable sequence number range.

Anoop

Of course; you are correct.

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