-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Iljitsch van Beijnum wrote: > On 18 mei 2009, at 22:51, Joe Touch wrote: > >> That is equivalent to a case where some packets have more TCP or IP >> options than others. I would expect TCP would retransmit the lost >> packets, and I would not expect a synchronization between the >> smaller-packet payload frequency and the retransmission, so since these >> smaller packets are sufficiently infrequent, a modern TCP (with SACK, >> e.g.) ought to handle it fine. > >> I.e., reporting the "large majority" MTU ought to be appropriate, rather >> than claming down on the smallest MTU on the path. > > Hang on, are you saying to just drop the larger packets without sending > back a too big message? No. I was wondering whether the path should report back the dominant size or the minimum. As you note below, if we have protocols that won't function when the larger packet gets through, we have a problem. That effectively means the MTU is the smaller number, i.e., that compression may save BW, but cannot support a larger MTU even if it is dominant. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRzsUACgkQE5f5cImnZrtjDQCguj0eNLpbYHdQRtzXVUIBjJo1 9VYAoJQL1XPzsAwGqg/aiiwTT3QYoEgi =XJFV -----END PGP SIGNATURE-----
