Subject: [tsv-area] Path MTU discovery when having varying MTU

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 May 2009 15:33:51 +0200

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.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 May 2009 16:15:04 +0200

> and what you think should be done about it.

If the large majority (say, more than 95%) of the packets can be  
compressed to some reasonably predictable size, but a few need to be  
larger, then it's probably a good idea to report back an MTU that  
accommodates the common case efficiently, and handle the packets that  
end up larger than that with fragmentation.

Another issue with IPsec encryption is that the encryption algorithms  
impose a certain block size. This means that if the packet doesn't fit  
in an integer number of blocks, there must be padding. So it's much  
better to send packets that are a few bytes shorter but exactly fill  
up the compression blocks rather than fill the packet entirely and  
carry padding bytes.

---

From: John Heffner <[email-masked]>
Date: Mon, 18 May 2009 09:40:42 -0700

Does rohc place an upper bound on the compressed header size?  It
seems the easiest/safest thing to do will be to use this in the
determination of MTU, and apply this MTU uniformly.

  -John

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 May 2009 13:51:56 -0700

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 May 2009 23:02:22 +0200

> 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?

If this large packet is needed to set up state in the decompressor, it  
needs to go through the tunnel.

If it doesn't set up compression state, the retransmissions aren't  
going to be smaller to the data will never get there.

Or are you assuming that the processing happens on the source host? I  
was assuming somewhere in the middle of the network.

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 May 2009 14:10:29 -0700

Iljitsch van Beijnum wrote:
> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 May 2009 23:14:09 +0200

On 18 mei 2009, at 23:10, Joe Touch wrote:

> if we have protocols that won't

Not necessarily. PMTUD for tunnels is just an optimization. There is  
no reason why you couldn't take full size inner packets and  
encapsulate them in an outer packet that is then fragmented.

Now doing that for 100% of the packets isn't great, but doing it for  
5% of the packets could very well be the right choice.

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 May 2009 14:17:11 -0700

Iljitsch van Beijnum wrote:
> Not necessarily. PMTUD for tunnels is just an optimization. There is no
> reason why you couldn't take full size inner packets and encapsulate
> them in an outer packet that is then fragmented.

You wouldn't know to do that unless you had a different idea of the MTU
at the endpoint. Or are you suggesting that ROHC do this (I don't think
it would)...

> Now doing that for 100% of the packets isn't great, but doing it for 5%
> of the packets could very well be the right choice.

Sure - but we'd be relying on that.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 May 2009 23:33:00 +0200

> at the endpoint. Or are you suggesting that ROHC do this (I don't  

Suppose the MTU is 1500, IPsec takes 50 bytes and ROHC may add 4 bytes  
worst case but saves 32 bytes on average (completely made up numbers).  
Now:

- packets smaller than 1500 - 50 - 4 = 1446 bytes can always be  
carried without trouble, so nothing special happens

- packets larger than 1500 - 50 + 32 = 1482 bytes can never be carried  
without fragmentation, so send a too big message.

- packets between 1446 and 1482 bytes will usually compress to  
something that can be carried without fragmentation, so we don't send  
a too big message. However, they may not compress, in which case the  
resulting packet is larger than 1500 bytes. We then fragment the  
packet upon sending and reassemble before detunneling.

The whole thing can be made dynamic so in the range 1446 - 1482 we  
don't always fragment but rather when we see that we fragment too  
much, we lower the MTU value reported back to sources until the level  
of fragmentation is within reason.

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 May 2009 14:37:42 -0700

Iljitsch van Beijnum wrote:
> worst case but saves 32 bytes on average (completely made up numbers). Now:
> 
> - packets smaller than 1500 - 50 - 4 = 1446 bytes can always be carried
> without trouble, so nothing special happens
> 
> - packets between 1446 and 1482 bytes will usually compress to something
> that can be carried without fragmentation, so we don't send a too big
> message. However, they may not compress, in which case the resulting
> packet is larger than 1500 bytes. We then fragment the packet upon
> sending and reassemble before detunneling.
> 
> The whole thing can be made dynamic so in the range 1446 - 1482 we don't
> always fragment but rather when we see that we fragment too much, we
> lower the MTU value reported back to sources until the level of
> fragmentation is within reason.

That's fine if that's what ROHC already does.

It's not fine if this is what you expect and ROHC dumps the too-big
packets between 1446 and 1482 on the floor.

I agree that some fragmentation like this might actually be a big win.
However, we're also assuming that the receiver reassembly happens fast
enough that the packets aren't delayed - i.e., if they are sent 'slow
path' in the receiver (if there is such a thing, and there could be,
e.g., on hardware-assisted hosts), then this would muck up the ROHC
mechanism...

Joe

---

From: John Heffner <[email-masked]>
Date: Mon, 18 May 2009 18:13:46 -0700

> than claming down on the smallest MTU on the path.

I think this would only be appropriate if the endpoint fragments, not
drops, packets that are too big to transmit, but smaller than the
reported MTU.  Then choosing the MTU becomes largely a cost
optimization problem.  Dropping some (at best) random fraction of
packets seems like asking for trouble.  It would also break rfc4821.

  -John

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 May 2009 11:08:23 +0200

Hi (as an individual contributor)

So this is IPsec tunnel mode which is commonly used for VPN, which means
that one of parties are quite likely behind a NAT or at least a
firewall. Thus, relying on IP fragmentation is likely to mean, all
fragmented packets dropped on the floor by the middlebox. Especially
when using IP/UDP/ESP for NAT traversal.

Also, the segmentation mechanism that ROHC has is currently defined to
be turned off. The ROHC people can fill in the motivation for that. One
is clearly the need to keep state in the tunnel end-points for reassembly.

So options in this space seems to be:

For the next 3 options I assume that ingress will discard packet and
send ICMP back if the packet is larger than the ROHC MTU set and has DF
set.

1. Set an commonly supported ROHC MTU and rely on IP fragmentation to
handle the few packet that gets expanded beyond the underlying MTU.
However, middleboxes makes it unlikely that this will work and lossing
the packets that gets expanded means failure to establish ROHC state
needed for the rest of the packets => 100% losses

2. Set a commonly supported ROHC MTU for the tunnel and use ROHC
segmentation to handle the packets that gets expanded beyond PMTUD.
Increased loss rate for important state establishing packets. Not
certain that the ROHC segmentation mechanism can work over reordering
transports.

3. Set ROHC MTU value to safe enough value that also packet expansion
has room within the underlying MTU. Reduced the gain of ROHC as the byte
savings are offset by increased packet overhead.

4. On packet basis see if fits and any packet with DF set which after
ROHC processing doesn't fit underlying MTU will be discarded. Will
result in varying values for the supported MTU being sent back by ICMP.
Affects either implementation complexity by rolling back state or
reduces error robustness by discarding encoded packets.

Are there more options?

Cheers

Magnus Westerlund

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 May 2009 12:18:17 +0200

On 19 mei 2009, at 11:08, Magnus Westerlund wrote:

> fragmented packets dropped on the floor by the middlebox.

Where do you get that?

I've never heard of fragmentation breaking consistently in  
middleboxes. This is from a system behind a NAT running peer-to-peer  
stuff for a while and communicating with some local systems. Since  
locally everything is ethernet and that communication is basically  
only TCP I don't think the fragments were local:

	94869703 total packets received
	112346 fragments received
	0 fragments dropped (dup or out of space)
	13 fragments dropped after timeout
	53614 packets reassembled ok

> is clearly the need to keep state in the tunnel end-points for  

If you can do IPsec and header compression then reassembly for a small  
percentage of all packets isn't unreasonable.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 May 2009 12:59:50 +0200

> [...] Not

As Carl pointed out, ROHC segmentation is efficient only for non- 
reordering links.
It is similar to AAL5, but does not use a length field.
Assuming the CRC is effective, it responds to undetected reordering  
with dropping the (reassembled) packet(s) affected with a likelihood  
of p ≈ 1-2**-32 (and delivering a bad one with q ≈ 2**-32).
I'm not happy about the security implications if it is not.

However, the IPsec sequence number might be good enough to reliably  
detect reordering or even to resequence before ROHC reassembly.  I  
think that might be the right thing to do, as ROHC segmentation is  
much better than IP fragmentation on a non-reordering link.

So there *was* something specific that ROHC could bring to the table...

The remaining problem is that the compressor needs to know the tunnel  
MTU.

On ROHC, I wrote:

> So what would you want the compressor to do?
> Run PLPMTUD (probes can be done by occasionally compressing badly*) on
> the tunnel and reject (ICMP unreachable/Frag needed) all DF/IPv6
> packets that would not fit with worst-case expansion?
> Probably safe, but somewhat expensive.
> [...]
>
> *) Yes, this needs way more text.
> You would need to compress badly whenever compressing a packet that,  
> badly compressed, would not fit the currently established safe  
> PMTU.  That unfortunately tends to shrink while compressing well,  
> which ROHC tends to do :-)

So let's replace that with:

> Run PLPMTUD (probes can be done by occasionally compressing badly*) on
> the tunnel and ROHC-segment all DF/IPv6 packets that would not fit  
> with worst-case expansion.
> *) This can be done by sending the packet on a separate CID with an  
> IR, with some impact on compression efficiency on the original CID.

Does that work?

Gruesse, Carsten

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 19 May 2009 13:25:17 +0200

Rohcers have to excuse me for double posting. I want pass on some
information from a parallel thread on the rohc list.

As Tero pointed out, there already is a way in ROHCoIPSec to send
packets uncompressed. The tunnel already keeps track of the MTU to
compensate for the IP, ESP AH headers. So adding ROHC overhead should
not a problem. Why not let the user decide whether or not to use ROHC
segmentation, IP fragmentation or sending large packets through the
uncompressed channel.

We could list pros and cons and give some guidelines.

/Calle

Tero Kivinen wrote:
> Carl Knutsson writes:
>> RTP profile can in worst-case add up to around 20 bytes. Header
>> compression works best for small packets. Large packets that doesn't fit
>> the MTU because of the overhead could be sent uncompressed or over a
>> channel without ROHC. The overhead for the uncompressed profile is only
>> a few bytes. This overhead is added to the PMTU field.
>
> With ROHC over IPsec there is already a way to express uncompressed
> packets without any overhead (i.e. if next header is ROHC protocol
> then packet is compressed with ROHC, if not then it is uncompressed),
> so sending uncompressed packets does not add any more overhead than
> what IPsec already adds.
>
> The amount of overhead for IPsec is per SA, as it depends on the
> protocol (ESP/AH) and about the algorithms selected for that SA, so
> adding ROHC overhead there should be easy. The ROHC overhead should
> take account the normal ROHC maximum header expansion and the ROHC ICV
> length.

Carsten Bormann wrote:
> As Carl pointed out, ROHC segmentation is efficient only for
> non-reordering links.
> Assuming the CRC is effective, it responds to undetected reordering with
> dropping the (reassembled) packet(s) affected with a likelihood of p â‰ˆ
> 1-2**-32 (and delivering a bad one with q â‰ˆ 2**-32).
> detect reordering or even to resequence before ROHC reassembly.  I think
> that might be the right thing to do, as ROHC segmentation is much better
> than IP fragmentation on a non-reordering link.
> 
> The remaining problem is that the compressor needs to know the tunnel MTU.
> 
> On ROHC, I wrote:
> 
>> badly compressed, would not fit the currently established safe PMTU. 
>> That unfortunately tends to shrink while compressing well, which ROHC
>> tends to do :-)
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 May 2009 13:41:19 +0200

>> fragmented packets dropped on the floor by the middlebox.

I am not saying that all middleboxes are broken. Only that there is talk
about middleboxes that doesn't handle fragmentation properly. I don't
have any numbers for how common this is. However, it definitely has been
raised in BEHAVE, for example when we discussed section 11 of RFC 4787.

> 
> I've never heard of fragmentation breaking consistently in middleboxes.
> This is from a system behind a NAT running peer-to-peer stuff for a
> while and communicating with some local systems. Since locally
> everything is ethernet and that communication is basically only TCP I
> don't think the fragments were local:
> 

> percentage of all packets isn't unreasonable.

No, I agree that this shouldn't be an issue. But it does introduce a
certain amount of buffering requirements on the reassembling side. I
think the ROHC people already have provided the real reason for their
choice.

Cheers

Magnus Westerlund

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 May 2009 13:41:24 +0200

On May 19, 2009, at 13:25, Carl Knutsson wrote:

> packets uncompressed.

True.  This would mean that the ROHCoIPsec path inherits the MTU of  
the tunnel minus IPsec overhead.
But one might want to do better than that, making use of the fact that  
for many packets IPsec tunneling overhead will be mostly cancelled out  
by the inner ROHC compression.

> The tunnel already keeps track of the MTU to

...where user is the person who configured the tunnel.
Sounds good to me.
As long as the signals that go to the end hosts allow them to do  
(PL)PMTUD predictably.

> We could list pros and cons and give some guidelines.

...which would pretty much elaborate on my previous sentence.

Gruesse, Carsten

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 09:42:48 -0700

One question:

I wonder whether ROHC should "skip compression" (if that's even
possible) on packets when compression would present a phantom MTU. I.e.,
IMO ROHC ought to be focused on reducing header overhead, which is
critical for small packets, but not on presenting a larger MTU than the
path can handle with a native (uncompressed) packet.

If that were the case, then all this MTU stuff would go away, AFAICT.

Joe

Carsten Bormann wrote:
> True.  This would mean that the ROHCoIPsec path inherits the MTU of the
> tunnel minus IPsec overhead.

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 11:14:41 -0700

Hi, all,

Here's what I'm wondering:

- -----------------

Does ROHC allow through packets that are not ROHC-tagged?

If so, the following may be a way forward:

When ROHC gets a packet that would have fit without ROHC, but won't now
(i.e., a packet that needs to be sent with the full header to resync
state AND needs to be tagged with the stream ID to enable that sync), then:

	a) send the packet without ROHC

	b) send a copy of the packet with no payload
	with the ROHC tags

(b) is to resync the state
(a) is to get the payload with the full MTU through when it won't
otherwise fit

Note that (b) is needed because a source may be sending a large flow of
MTU-sized packets, and there would be no way to send resync state otherwise.

This has the net effect of doing "fragmentation" except that it doesn't
fragment - either piece can be lost, and no reassembly is needed.

Would this suffice?

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 May 2009 20:44:08 +0200

> 	b) send a copy of the packet with no payload

That doesn't help much, because the only thing you save here is the  
"hey set up state for what follows" indicator in ROHC. Being  
unfamiliar with ROHC I'll go out on a limb and assume this is only a  
byte or so.

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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 11:51:56 -0700

Iljitsch van Beijnum wrote:
> That doesn't help much, because the only thing you save here is the "hey
> set up state for what follows" indicator in ROHC. Being unfamiliar with
> ROHC I'll go out on a limb and assume this is only a byte or so.

The tag is a byte, but we're refreshing the whole IP (and TCP) header
context for the subsequent packets.

> 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.

I'm trying to avoid having ROHC interfere with the E2E MTU of a non-ROHC
path.

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.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 May 2009 21:03:18 +0200

On 19 mei 2009, at 20:51, Joe Touch wrote:

>> the

> 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.

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?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 May 2009 12:10:25 -0700

Did someone say "tunnel MTU"?

The problem is that the tunnel is a link, and the link
needs to be consistent in its handling of packets of all
sizes in order for end-to-end mechanisms like RFC4821 to
work. Having the link sometimes able to pass, e.g., 1500
packets and other times not able to pass, e.g., 1480
packets is a recipe for confusion.

Someone said "use fragmentation", and we should take a
look at that. Someone else said "but not all middleboxes
pass fragments", and that may be true but I believe it
is highly likely that even those middleboxes will pass
*first* fragments (i.e., those with MF=1; Offest=0).

Enter SEAL (draft-templin-seal). SEAL is specifically
designed to ensure a solid MTU across the tunnel even
if there may be fluctuations in MTU sizes *within* the
tunnel. SEAL works by sensing outer IP fragmentation
within the tunnel then adjusting its sizing parameters
for SEAL segmentation accordingly.

So, let's say that we set a static MTU of 1500 on the
tunnel. Within the tunnel, the IPsec encapsulations
and rohc headers are added to inflate the size of the
packet beyond 1500. We now introduce the SEAL header
as a thin layer inserted as:

  IP(inner)/ESP/SEAL/UDP/IP(outer)

All SEAL is doing is inserting fields for controlling
a mid-layer segmentation and reassembly process that
occurs above the outer IP fragmentation layer but below
the inner IP fragmentation layer. Another name for it
is link adaptation.

When a packet is sent into the tunnel, and the path
MTU within the tunnel is not yet known, SEAL at the
tunnel egress will listen for any outer IP
fragmentation occurring within the tunnel and send a
report back to the tunnel ingress. The ingress will
automatically adjust its SEAL segment size to tune
out the outer IP fragmentation, and the inner IP
layer will continue to see a solid 1500 MTU.

This means that DF=0 in the outer IP header always.

Fred
[email-masked]   

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, May 19, 2009 11:15 AM
> To: Joe Touch
> Cc: [email-masked]; Carl Knutsson; [email-masked]; TSV Area
> Subject: Re: [tsv-area] [rohc] Path MTU discovery when having varying
MTU
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, all,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkoS9xEACgkQE5f5cImnZrv6pwCgqxCtz8ipEaChzeQAjaAVbMZL
> 1koAoKfN+hUua46yBG/XqMMNg3+MnS7S
> =Jtb2
> -----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 13:26:41 -0700

Iljitsch van Beijnum wrote:
> 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.

> 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

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 13:21:03 -0700

> Did someone say "tunnel MTU"?
...
> Enter SEAL (draft-templin-seal). 

That works only when we deploy SEAL at the endpoints. Short of
incorporating SEAL into ROHC, there ought to be other solutions that are
less complex...

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 May 2009 22:56:13 +0200

> 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.

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.

> that ROHC will never resync, and *everything* will get thrown on the

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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 14:14:57 -0700

Iljitsch van Beijnum wrote:
> 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.

> enough to fit upon retransmission it's safe to drop them if they do and
> we send a too big if they don't.
> 
> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 May 2009 23:25:43 +0200

On 19 mei 2009, at 23:14, Joe Touch wrote:

>> enough

> it too.

Yes, but then you would still almost never have full-size packets so  
the ROHC only saves bandwidth, not packets. Basically this will buy  
you a 1 byte larger MTU, not worth the trouble because the IPsec  
header already exposes you to PMTUD blackholes anyway.

Ideally, the decapsulator can tell the encapsulator what to do because  
the decapsulator knows about whether it's behind a NAT with  
fragmentation issues. But then there would have to be signaling that  
carries this information.

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 14:36:58 -0700

Iljitsch van Beijnum wrote:
> Yes, but then you would still almost never have full-size packets so the
> ROHC only saves bandwidth, not packets.

I wouldn't say only. The number of packets you save is still in the noise...

> Basically this will buy you a 1
> byte larger MTU, not worth the trouble because the IPsec header already
> exposes you to PMTUD blackholes anyway.

Using ROHC allows you 30 bytes more in the MTU if you try hard, but
causes this sort of hiccup on resync packets as a result. IMO, that's
more trouble than it's worth.

> carries this information.

Yeah - that's what Fred was getting at with SEAL, which has that sort of
signalling.

Joe

---

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Tue, 19 May 2009 23:45:08 -0400

> ...which would pretty much elaborate on my previous sentence.

I agree with the discussion here.  

For the sake of these drafts, how about we add brief discussion on the
following potential solutions:
-- applying ROHC segmentation
-- IP fragmenting packets post ROHC/IPsec processing 

Perhaps we simply document the benefits / considerations of these two
alternatives.  Also, now that ROHC segmentation is possible, we will
also need to change some of the current wording (which specifies that
segmentation is not used) in the IKEv2 and IPsec drafts.
 
If we wanted to open it up further, we could also look at the following
alternatives (however, these will deviate a bit more from what is
currently in these drafts):
--as Joe mentioned, if the ROHC packet exceeds the size of the MTU, just
transmit the uncompressed packet.  However, the drawback here is that
ROHC is statefull compression algorithm... and we could run into
problems in terms of context state invalidation (e.g., if the copy of
the packet with no payload gets reordered or dropped in the unprotected
domain).
--inner fragmentation, where the packet is fragmented and then
subsequently handed to the ROHC-enabled SA for compression and IPsec
processing.  However, AFAIK, I do not think that current ROHC profiles
can compresses packets/packet fragments (e.g., MF is STATIC-KNOWN, and
is always assumed to be 0), so such a solution could be a bit difficult
as well.

BR,
Emre

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 May 2009 10:43:56 +0200

> Ah - OK, that works. Not efficiently, but it works.

For TCP yes, not for UDP or other protocols.

> used primarily to reduce header overhead. It's a bit silly to do all

I am starting to think the same, simply declare the MTU that you know
will always work. With an IPsec tunnel, you will anyway have a smaller
MTU than the regular link one, so descreasing it some bytes more should
not be an issue.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 May 2009 10:51:40 +0200

> segmentation is not used) in the IKEv2 and IPsec drafts.

I think this has issues for a specification that is intended to
interoperate. One end point sends ROHC segmentation, the other end
doesn't implement it => packet losses for all packet that attempts to
use it. Relaying on IP fragmentation might work, but should probably
make it clear that the tunnel egress MUST implement IP defragmentation
to allow for this option.

> is always assumed to be 0), so such a solution could be a bit difficult

My intention was not to redesign the world. Simply to take the issue
into consideration and make it clear what should be done.

Cheers

Magnus Westerlund

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 May 2009 12:26:25 +0200

On May 26, 2009, at 10:51, Magnus Westerlund wrote:

> One end point sends ROHC segmentation, the other end
> doesn't implement it

We did not really make segmentation optional in RFC3095/RFC4995, but  
setting MRRU to 0 effectively disallows the use of segmentation, so  
its use can indeed be negotiated.  Enabling the use of ROHC  
segmentation in HCoIPsec would entail supporting negotiation of the  
MRRU option in IKE-ROHC (which is currently hardwired at 0).

Of course, options and negotiation do not necessarily aid  
interoperability.  But then, "extending the MTU" would be an  
optimization, and implementations can always fall back on the worst- 
case MTU*) approach Joe suggested, if the tunnel MTU is large enough  
to support the minimum MTU.

Gruesse, Carsten

*) I haven't done the work yet to verify that there is a good way to  
compute this worst-case MTU.
But I think it feels right.