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

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 02 Dec 2004 15:55:51 +0100

Ok, to re-awaken the discussion on ack numbers in ROHC-TCP, I thought I'd list 
the options we have.

- The implicit ACK number scaling in bidirectional deployments seems to only 
have the support from Mark, while myself, Lars-Erik, Ghyslain and Carsten have 
doubts about the complexity required (Mark, if you want to keep this, please 
explain IN DETAIL how you want it to work). I think we should leave this out of 
the spec. (if I have misjudged the opinions of anyone or if someone else finds 
this to be compelling, please yell out before we scrap it)

This leaves us with (at least) the following different roads for this:
a) Only send unscaled ACK numbers. Not very optimal, will often have to send 
about one byte extra compared to a scaled scheme. Simple and clearly interoperable.
b) Explicit scaling (ack_stride, 16 bit value) by letting the compressor send 
over a scaling value in a compressed packet (for example, this value could be 
transmitted in the dynamic chain and co_common, but nowhere else). How this 
value is inferred by the compressor would be an implementation detail, so that 
it can use the reverse-directional stream, it could look at the traffic or it 
could use some proprietory out-of-band signalling etc. In this scheme, only one 
scaling value is legal at any one time and if the ack number change rate is very 
variable, then either we need a frequent update of the stride or we have to send 
unscaled values until the same stride "comes back". Not being a TCP expert, I 
can't really say how much gain/loss this would be in the end, but I think it 
seems worth considering.
Also, if we go for this strategy we need to decide how to handle it at context 
replication (always, never or optional).
c) optional feedback option sending the ack_stride (the sending entity's 
decompressor could take this value from the co-located compressor). This is like 
the bidirectional stuff but it is "explicit and optional" instead of "implicit 
and mandatory". Downsides are the delay before this can be used and also this 
will probably lead to some sliding window of scaling values so that 
compressor/decompressor keep in synch. I'm not for such a solution, since it 
seems complex and slightly evil.

I could consider option b), but as I stated, I cannot really estimate the gain, 
so possibly a) is good enough.

So, what should we do? Opinions welcome.

/Kristofer Sandlund, Effnet AB

Ghyslain Pelletier (LU/EAB) wrote:
> 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.
>>
>>_______________________________________________
>>Rohc mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/rohc
>>
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc

-- 
()  ascii ribbon campaign - against html mail
/\                        - against microsoft attachments

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

---

From: "West, Mark" <[email-masked]>
Date: Tue, 7 Dec 2004 23:36:18 +0000 (GMT)

Hi all,

Apologies for the 'usual' delayed-ACK...

Comments in-line.

Cheers,

Mark.

> this to be compelling, please yell out before we scrap it)

I'm assuming that this is referring to the proposal to use sequence
numbers in one direction to infer acks in the reverse direction?  (it's
just that I wouldn't call this scaling, but that's being picky!)

Well, I cannot deny that I'm still rather attached to the idea of this
scheme -- it just seems like a really nice idea from the TCP perspective.
Also, for a more applicable argument, it's going to have most effect on
'pure ACK' packets which are, in fact, 'pure overhead'.  So, arguably,
these are a good target to try and squeeze harder...

However I also cannot deny that there are a number of issues to be ironed
out and corner cases to be thought through.  Having said which, I still
believe that it is possible to specify it in a reasonable and manageable
way.

If anyone actually thinks that it would be useful for me to write a more
detailed description, for discussion, then I'm quite happy to do that.
However, I get a fairly strong sense that it wouldn't be worth the effort;
certainly nobody has indicated any interest following this mail.  In which
case, I bow to the majority view...

> replication (always, never or optional).

I'm really not sure how much benefit you'd actually get in this case (in
terms of overall average compressed header size).  There are definitely
going to be cases where large gains can be made: some flows will have long
runs of 2 x MSS intervals in the ack flow.  This will work just as well as
deriving acks from seqno, in that case.

However, in many other cases you will be faced with the 'how long will
this persist / is it worth setting the scaling now / when will I have to
change it back' trade-off.  Ok, there's scope for clever compressors to do
better; but if it's too complex, who will bother?

Carsten's observation suggests that this might typically be able to save a
few bits per header, but how often do you have to send the 16-bit
ack_stride (+ the base-size of the header to carry that information).

> seems complex and slightly evil.

Surely this case is more the remote end-point being able to 'suggest' (in
a feedback option) suitable value(s) for scaling, as defined in (b)?  In
other words, I see this as suggesting a refinement to (b) rather than a
separate scheme.  (I agree with 'complex and slightly evil' as an
assessment of this scheme on its own...)

> so possibly a) is good enough.

I would consider (b), too.

I suppose that I have difficulty accepting the statement "(a) is good
enough" when there are clearly ways of achieving better compression than
this.  Although I freely accept that the trade-off of complexity vs.
saving is not obvious.

If we're going to take *that* strong a line on complexity, then (a) is the
only way to go, of course.  And we probably ought to take a good hard look
at the draft to make sure that it's really as simple as we think/hope.

Cheers,

Mark.

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 08 Dec 2004 12:55:26 +0100

Hi Mark. Comments inline.

> Apologies for the 'usual' delayed-ACK...

We're used to it by now :)

> believe that it is possible to specify it in a reasonable and manageable

As Carsten pointed out, one would need to "point out" both channel ID and CID 
for the reverse context which I'm taking the scaling from. You would also have 
to send the "reverse-direction MSN" to know which scaling value to use (the 
sliding window you refered to earlier). Therefore, to use the dual-directional 
implicit stuff would probably require an overhead of at least a couple of bytes. 
And some new fields to the packet formats which would add even more packet 
formats. And with this kind of overhead, I think that an explicit stride value 
would be as efficient if the compressor is smart. See more below.

> better; but if it's too complex, who will bother?

That's pretty much my point. If it is explicit, it will be up to the compressor 
to decide if it wants to use this or not. Therefore, he _can_ use the 
reverse-directional seq to obtain a suitable stride, or any other smart trick he 
likes. Making it optional to me means that one can allow a lot more complexity 
on the compressor side, as long as the decompressor does not have to be really 
smart (and with this scheme, I think the decomrpessor can be dumb no matter if 
the feature is used or not).

> ack_stride (+ the base-size of the header to carry that information).

If the compressor is really bright and uses a lot of "good ideas" when deciding 
the stride value, it could be efficient. And if the compressor is more "stupid" 
(or the flow is not suitable for ACK scaling), it should just ignore this 
feature altogether. Therefore, I think we should try to specify this idea. If it 
turns out that it has some flaws, we can drop it before publication.

> assessment of this scheme on its own...)

Yep, you're right. This would be a complement to b). But since we both feel it 
is evil, I think we should leave it out for now.

> this.  Although I freely accept that the trade-off of complexity vs.

Ok, let's try to get b) working then. Some questions:

- When should we have scaled ack compression? Should it only be used for "pure 
ACK streams (i.e. as in packet 4 in baseheaders.txt), should it be usable on 
streams that have changes to both ack and seq, should it be usable in co_common 
and/or packet 10, should it be useable ir IR/IR-DYN? Opinions please.

- When should we be able to transmit the ack_stride factor? My suggestion would 
be co_common and possibly as an optional in tcp dynamic chain. Or do we want to 
add it to other packet formats as well?

- Are there any issues with this? We need to be very clear on what happens when 
the ack_stride is zero, so we don't get into slope-ish zero-division discussions 
later on. My suggestion is that a stride of zero means that we should not use 
scaled packet formats. Do we set a default-value for ack_stride and in that case 
what is it (zero or nonzero)?

If I get some answers to these questions I can add some things to 
baseheaders.txt and suggest some text for the tcp-draft explaining what this is.

> at the draft to make sure that it's really as simple as we think/hope.

No, we don't need to discard everything that is complex, but my feeling is that 
the bidirectional stuff seems hard to get interoperable due to the coupling of 
flows from different channels/context spaces. But, I agree that it would be a 
good idea to go over the draft and try to see if we do "too much" for some 
fringe cases.

I'm going to write up another mail with some outstanding discussion items on the 
packet formats in a while, but please provide some feedback on this stuff so I 
can start working on a solution.