-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Westerlund wrote: > This email is BCC to a number of list. Please respond to the TSV-area list. > > In the AD review of the documents for defining Robust Header Compression > (ROHC) over IPsec: http://tools.ietf.org/wg/rohc/draft-ietf-rohc-hcoipsec/ > > I picked up on a issue that has been mentioned before but not really > been dealt with. Namely the varying MTU for packets entering this tunnel. > > So this work is to enable so that ROHC can compress the inner IP, > transport, etc headers inside an IPsec tunnel to save bandwidth that > way. ROHC is a stateful compression technology which can result in that > the headers being compressed can be both slightly bigger as well as much > smaller. Thus the effective MTU for a particular packet inside an IPsec > tunnel with ROHC varies depending on which packet in a sequence it is. > This will create some issues for any path MTU discovery mechanism, where > a smaller packet may result in a ICMP TOO BIG while a slightly larger > packet doesn't. > > So I am interested in what issues you see arising with this technology > and what you think should be done about it. 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. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRymwACgkQE5f5cImnZru7dgCdGhrEYS6YjtocD4+Dm7Ahxhqw jXwAnizcDfTtNb4m1Pw/Lh2cSvsGb2kB =IPn/ -----END PGP SIGNATURE-----
