Hacker News Reader

Comment by vardump | Hacker News Reader

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.

View on HN

See perhaps "Best CRC Polynomials":

* https://users.ece.cmu.edu/~koopman/crc/

Thanks. Pretty nice!

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.

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

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.

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.

Right, vaguely aware of that, but been a while. Thanks for correcting!

Reply on news.ycombinator.com