Subject: [rohc] ROHC-TCP, ack number compression

From: "West, Mark" <[email-masked]>
Date: Fri, 19 Nov 2004 01:30:53 +0000 (GMT)

Hi all,

I've been doing a little bit more thinking about 'ack compression' --
currently we're just handling it as a 'normal' LSB encoding (compared with
seqno, where we allow for scaling by the payload size when that remains
stable).

There appear to be three possible things to do:

1/ stay as we are;

2/ do some sort of generic ack optimisation (a la Carsten's thought); or

2/ do some sort of bi-directional ack optimisation.

In no particular order... ;-)

(1) has the advantage that it's simple and we know it'll work.  However,
it is clear that it is going to cost some bits in, for example, the
reverse-path of a bulk data download:
	Ethernet MTU assumed ~  1460 octets
	Ack ratio assumed == 2
	Resilience to loss assumed ~ 4 packets
		=> 14 bits of Ack Number

Whatever happens, we need to support this case -- it's the one that'll
work regardless of anything else!

(2) relies upon the fact that payload sizes tend to be multiples of powers
of 2 (4, 8, 16, ...) which does appear to be the case (and, for small
multiples, makes sense from an implementation perspective).  If a run of
packets with payload sizes of a multiple of (say) 16, we could scale the
ack.
	Scaling of 16 -> 4 bits saved
		=> 10 bits of Ack Number

But... I can't see anyway of doing this without explicitly sending an 'ack
scale' value to the decompressor: I'm not convinced that this is the sort
of thing that you want to derive on the fly?  (You *could*, but...)

Also, NB, if we do think about doing this for ackno, then you could do it
for seqno as well (although I think that the general 'stable payload size
scaling' is plenty good enough!)

(3) relies upon the fact that, whilst it need not be the case, it is
highly likely that an ack value in the reverse path is directly acking a
packet in the forward path (i.e. it contains seq_no + payload_len). Thus,
if you know that the other endpoint has seen the packet in the forward
direction [you have decompressed the packet!], then you can identify an
ack by indicating which packet is being acked (by the MSN).

If you assume that the ack flow more-or-less moves in step (i.e.
increasing MSNs), then you get:
	Ack ratio assumed == 2
	Resilience to loss assumed ~ 4 packets
		=> 3+ bits of Ack Number (actually would need to allow
                                          for more of a window)
The advantage, then, is the potential saving.
The disadvantages are:

- it only works when the compressor/decompressor can share data;

- the endpoints have to store histories of 'expected' ack numbers and the
compressor and decompressor have to manage this shared state such that it
doesn't get out of synchronisation [this is single biggest complexity
issue, for me];

- the issue of switching between 'MSN-based' and 'raw-ackno-based'
compression (which, if we assume only happens rarely, shouldn't be too
much of an issue).

Comments?

Cheers,

Mark.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 22 Nov 2004 14:54:20 +0100

> Summary:
> 
> - uncompressed ack           : 32 bits
> - 'vanilla' ack compression  : 15 bits
> - bi-directional compression :  4 bits
> - implicit ack stride        : ?? bits
> - explicit ack stride        : 10 bits ?

Mark,

Your discussions are reasonable, and my conclusion from
this is that the extra savings we can get from bi-dir
compression is less than an octet, and that is in the
case where the pre-assumptions for bi-directional
compression are met. If we then consider that the ack
field is only one part of the whole story, where we
actually look at the complete IP/TCP header, I do not
see that it is worth the conceptual complexity cost.

The reasons for me opposing bidirectional compression
are clearly based on two aspects, the fact that I do
not like the concept in principal (which is for sure an
argument that can't easily be measured in numbers =),
and my conclusion that the gain would not be 
"significant" (i.e. another parameter that is clearly
a matter of subjective "feelings") compared to the cost.
Previous experience from doing fancy optimizations
tells me we should be really careful, but I do not have
any additional detail arguments to bring at this point.

/L-E

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 23 Nov 2004 12:23:39 +0100

Hi all,

At first I thought it could be good to consider some kind of bidirectional compression, and thanks for information that was sent regarding this.

However, it now seems to me that this thread is converging towards keeping ack compression as it is.
After reading the thread carefully, this is at least what I am in favor of right now.

I.e. let's keep 'vanilla' ack compression as it currently is.

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> West, Mark
> Sent: den 23 november 2004 01:37
> To: Carsten Bormann
> Cc: [email-masked]'; Kristofer Sandlund; Lars-Erik Jonsson (LU/EAB)
> Subject: Re: [rohc] ROHC-TCP, ack number compression
> 
> 
> 
> > > And I don't think it's a complex 'negotiation': the 
> compressor *does*
> > > need
> > > to signal that it is storing ack numbers
> >
> > Also, we need some way to bind the forward and reverse channels, as
> > well as the CIDs.
> 
> True -- something that I had managed to ignore... :-)
> 
> > This may be interesting on some channels.
> > (There was a reason we did the state ID dance for SigComp...)
> >
> 
> Good point: I'd managed to overlook flow separation issues 
> (for example).
> But do you really think that this is as messy as SigComp..?  We have a
> little more control over the endpoints.  And so I don't think that the
> SigComp state model is directly applicable.  (But I've still 
> probably been
> guilty of over simplifying...)
> 
> Cheers,
> 
> Mark.
>