3 ms·

It'd be great to have an MTU of say 64 KiB or greater. Although I guess you'd also need a longer than 32-bit CRC to detect all the possible 3 bit errors past 1

It'd be great to have an MTU of say 64 KiB or greater. Although I guess you'd also need a longer than 32-bit CRC to detect all the possible 3 bit errors past 11 kB frame size. A 40-bit CRC would be sufficient, at least up to 188 kB frame size or so.

ggm 3y ago
Some people say for TCP, smaller packets give better acknowledgement pacing. ISCSI is kinda over local, single switch links for me, but general purpose TCP streamed data it may well be "smaller is better" for rate estimates and window management
- vardump 3y ago
  Nothing prevents you from using a smaller MTU... well "TU" for TCP frames. Less packets to process would speed things up. Fever headers to process. Also if your TCP flow bandwidth is counted in tens or hundreds of gigabits per second, there's still going to be plenty of ACKs.
  - bewaretheirs 3y ago
    MSS (maximum segment size) is the term at the TCP layer. Each end of a connection can (and usually does) declare its MSS in a TCP option in the first packet it sends. Advertised MSS, interface MTU, and route MTU can all constrain packet sizing. Using large-MTU routes for internal destinations can work well.
    - vardump 3y ago
      Right, vaguely aware of that, but been a while. Thanks for correcting!
throw0101d 3y ago
See perhaps "Best CRC Polynomials": * https://users.ece.cmu.edu/~koopman/crc/ https://users.ece.cmu.edu/~koopman/crc/
- vardump 3y ago
  Thanks. Pretty nice!
zamadatix 3y ago
If we were redoing Ethernet I wouldn't mind removing the CRC completely. If you want end to end reliability you should do it in the layer above ethernet. If you want link per link packet validation in a network we've already been layering advanced FEC algorithms at the physical layer for high speed Ethernet. The advantage of the latter being it's both optional and replaceable without requiring even more dynamic bits or redundant functionality in the layer 2 packet. Then on MTU make it a 32 bit field instead of a 16 bit field in case anyone wants to make hardware that supports more than 64k in the future.

ggm 3y ago

Some people say for TCP, smaller packets give better acknowledgement pacing. ISCSI is kinda over local, single switch links for me, but general purpose TCP streamed data it may well be "smaller is better" for rate estimates and window management

vardump 3y ago
Nothing prevents you from using a smaller MTU... well "TU" for TCP frames. Less packets to process would speed things up. Fever headers to process. Also if your TCP flow bandwidth is counted in tens or hundreds of gigabits per second, there's still going to be plenty of ACKs.
- bewaretheirs 3y ago
  MSS (maximum segment size) is the term at the TCP layer. Each end of a connection can (and usually does) declare its MSS in a TCP option in the first packet it sends. Advertised MSS, interface MTU, and route MTU can all constrain packet sizing. Using large-MTU routes for internal destinations can work well.
  - vardump 3y ago
    Right, vaguely aware of that, but been a while. Thanks for correcting!

throw0101d 3y ago

See perhaps "Best CRC Polynomials": * https://users.ece.cmu.edu/~koopman/crc/ https://users.ece.cmu.edu/~koopman/crc/

vardump 3y ago
Thanks. Pretty nice!

zamadatix 3y ago

If we were redoing Ethernet I wouldn't mind removing the CRC completely. If you want end to end reliability you should do it in the layer above ethernet. If you want link per link packet validation in a network we've already been layering advanced FEC algorithms at the physical layer for high speed Ethernet. The advantage of the latter being it's both optional and replaceable without requiring even more dynamic bits or redundant functionality in the layer 2 packet. Then on MTU make it a 32 bit field instead of a 16 bit field in case anyone wants to make hardware that supports more than 64k in the future.