Subject: Re: [mobile-ip] PMTU, ROHC and piggybacking (was IPsec, IKE, MIPv6 and concensus)

From: Erik Nordmark <[email-masked]>
Date: Fri, 7 Sep 2001 16:21:52 +0200 (CEST)

[Can we fix the reply-to stuff for this mailing list? I'd like
to be able to tell which emails are replies to stuff I wrote without
looking for "Erik Nordmark wrote:" in the body of the email.]

> hi,
> 
> Erik Nordmark wrote:
> 
> > Agreed from the perspective of IPsec.
> > (There are still PMTU, ROHC? issues etc with piggybacking.)
> 
> whats are the PMTU issues? you check the data packet. if you 
> can add the BU option to the packet without exceeding the
> PMTU, you piggyback. otherwise you dont. you send the BU
> as a separate packet. only the sender has to do this check.

I don't understand whether or not including a BU in a TCP SYN
exchange will/should have any effect on the MSS vs. PMTU 
calculation. Those more up to date on TCP can presumably help.

But in any case, the PMTU stuff adds complexity to the specification.

> its not an issue for ROHC either, we have an implementation 
> here. when ROHC comes across a packet bigger than what it 
> is supposed to be, it skips compressing this particular 
> packet. and this packet is received in the clear. we do 
> exactly this. we have run tests with a simple RTP 
> application. the typical packet in the data stream 
> (that is being compressed in our experiment) is 
> (IPv6 header + home address option + UDP header + 
> RTP header + payload). if a packet received by the 
> compression engine is bigger  than this, we skip 
> compression on this packet. i dont know whats the big 
> deal. it works. somebody please correct me if i am 
> wrong.

Does such an implementation gain any performance benefit by using piggybacking?
 If you assume that an RTP packet gets compressed to N bytes (including
the RTP header) plus RTP payload even when the previous RTP packet
packet did not go through compression you get something like this:

Number of bytes over wire for one RTP packet plus on BU.

No piggybacking:

Packet 1:
	IPv6
	BU

Packet 2:
	IPv6+UDP+RTP+payload compressed to N+payload

sum: 
	IPv6+BU+N+payload

Piggybacking:

Single packet = sum:
	IPv6+BU+UDP+RTP+payload

Difference:
	UDP+RTP-N

Thus you gain by not doing piggybacking.

In order to gain in the piggtbacking+ROHC case the ROHC compressor
must identify that the piggybacked packet is part of the RTP context
in question and compress everything but the BU.

  Erik