-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Iljitsch van Beijnum wrote: > On 19 mei 2009, at 22:26, Joe Touch wrote: > >> The problem is that when a 1480 packet arrives and you do ROHC, it's >> 1450 only most of the time; sometimes it's 1481 because it needs the >> full original header and the ROHC stream ID. Those "big" packets are >> required by ROHC to resync, and would be dropped after IPsec. > > In those cases the packet would be truncated so there's enough for ROHC > to resync but obviously the receiver doesn't get the original packet so > the sender will have to retransmit. This is not a problem if the > retransmitted packet does compress so it fits. Ah - OK, that works. Not efficiently, but it works. > So as long as we can accurately predict which packets will compress > enough to fit upon retransmission it's safe to drop them if they do and > we send a too big if they don't. > >> Even if TCP does fast retransmit, at some point the stream needs to get >> through a payload of 1481, which will never get through. The result is >> that ROHC will never resync, and *everything* will get thrown on the >> floor... > > Didn't you just suggest to just send enough of the original packet to > make ROHC do its thing? That piece of the packet should be small enough > to always fit. Yes, except that I also suggested sending the packet without any ROHC on it too. That works only if ROHC is NOT used in the computation to increase the MTU. I.e., IMO ROHC ought NOT be used to increase the MTU. It ought to be used primarily to reduce header overhead. It's a bit silly to do all this work for 2%. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEyFRE5f5cImnZrsRAiqSAJ4t5aAfbciiuByB89anJsz5N2IErACfVpH+ pSR36PrPMlwPIfkTftak2dg= =ZjX5 -----END PGP SIGNATURE-----
