-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Iljitsch van Beijnum wrote: > On 19 mei 2009, at 20:51, Joe Touch wrote: > >>> Assuming that we can predict if and how well a certain flow will >>> compress, we could also simply drop a) and send back a too big with the >>> size that will compress to what fits inside the MTU and just send b) >>> through the tunnel. > >> Your solution tells the endpoint that all packets have to be smaller, >> even when subsequent packets with the large MTU would have headers that >> compressed enough to make space for the ROHC header. > > No, what I mean is that if you get a packet that is 1500 bytes, your > IPsec is 50 and ROHC for this packet at this time is +1 but we know that > subsequent packets will be -30, then we return an MTU of 1500 - 50 - -30 > = 1480. Next packet is 1480, we do ROHC and it's 1450 and then IPsec = > 1500 and we're in business. 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. > Interesting question about what we do with packets that conform to the > compressable MTU. In this case, 1480. Too big is unnecessary because the > source is already sending small enough, but we'd have to drop (the data) > anyway. With TCP, fast retransmit will catch this. Are there any corner > cases we should worry about? 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... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKExYBE5f5cImnZrsRAjzkAKC5f0FkIw7BwWLuLQ4i6msLgo7jUQCfQkfk BPFI1cqw23Xpts7IziQGLXY= =G1PP -----END PGP SIGNATURE-----
