Subject: RE: [rohc] ROHC-TCP issue: U/B mode, mode transition, and MSN

From: "Qian Zhang" <[email-masked]>
Date: Thu, 23 May 2002 19:59:32 +0800

Lars-Erik and Mark,

Thanks for the feedback on U/B mode and feedback related issue.

Please see my comment inline.

Regards,

Qian & Hongbin

> 
> >>> QZ: Transition from U-mode to B-mode
> >>>
> >>> When there is feedback channel available, the decompressor
> >>> may at any moment decide to initiate transition from U-mode
> >>> to B-mode. Any feedback packet carrying a CRC can be used
> >>> with the mode parameter set to B. The decompressor can then
> >>> directly start working in B-mode. The compressor transits
> >>> from U-mode to B-mode as soon as it receive any feedback
> >>> packet that has the mode parameter set to B and that passes
> >>> the CRC check.
> 
> LEJ: Explicit mode information is really not needed for this.
> The decompressor can just start to send feedback, and continue
> to do so. Whenever the compressor receives a feedback message,
> it can disable periodical updates.

Agree. 

> >>> QZ:Transition from B-mode to U-mode
> >>>
> >>> The decompressor can force a transition back to U-mode if it
> >>> desires to do so. Any feedback packet carrying a CRC can be
> >>> used with the mode parameter set to U. The decompressor can
> >>> then directly start working in U-mode. The compressor
> >>> transits from B-mode to U-mode:
> >>> 1) as soon as it receive any feedback packet that has the
> >>> mode parameter set to U and passes the CRC check, or
> >>> 2) for an enough long time period (TIMEOUT), it hasn't
> >>> received any feedback with the mode parameter set to B.
> 
> LEJ: This indicates that, as for ROHC RTP, one would really need
> at least a 2-way handshake if one wants to go back to U-mode,
> since the compressor must know when to stop expecting negative
> acks, before the decompressor stops sending them. In ROHC RTP
> we already had the mechanisms for mode transfer, so we added
> the ability to go back to U-mode, but I am not sure we really
> must support that.
>

> MW: So it looks like we can probably go with a fairly loose separation

> between 'U' and 'B' mode?  (i.e. The very existence of feedback is 
> sufficient to indicate the presence (and use of) a feedback channel). 
> This means that we only need to convey MSN information on some packets

> and, although it may be hard to determine the probability for this, a 
> fairly arbitrary choice is probably a workable 'engineering solution'!

We do agree that we can probably go with a fairly loose separation
between 'U' and 'B' mode. However, there is still a problem left about
how the decompressor side sends the feedback. As long as the decompress
may send the feedback with different frequency, then we still need
specify how to carry the feedback information.

> >> MW: Qian and Hongbin have identified the aspect of TCP
> >> compression that makes this an interesting challenge:
> >> there is nothing obvious in the TCP/IP header that can be
> >> easily used as an identifier for acknowledgements.
> >>
> >> We seem, therefore, to come to 3 or so choices:
> >> 1/ Have 2 different packet formats for U and B mode (The B
> >>    mode packets containing some kind of sequence identifier)
> >> 2/ Have only 1 set of packet formats.
> >>    This format set supports an explicit identifier, and:
> >>       2a/ We keep the U/B mode distinction
> >>       2b/ There is only one mode
> 
> LEJ: If we could avoid, or at least softening up the concept of,
> different modes, that would absolutely simplify things.
> 
> 
> >> 3/ Make use of TCP/IP header fields to construct an identifier
> >>    for acks (Avoiding any need for explciit identifier)
> >>
> >> Taking these in reverse order, it seems natural to view the
> >> feedback as an optimisation (short-circuiting U-mode repeated
> >> transmission and allowing failure reporting through negative acks).
> >> In which case, it is not clear that to me that there is any need
> >> to explicitly identify a U and a B mode...
> 
> LEJ: I totally agree, one mode with improved performance if feedback
> can be used would be a nice solution. We should try to avoid
> creating a complex mode concept, if not needed.
> 
> 
> >> MW: The advantage of (2) is that the identification is readily
> >> available for the decompressor to use for an acknowledgement
> >> (and is small).
> >
> > QZ: If option (2) includes MSN in the uniform packet format, we
> > have to give the probability whether MSN is present or not
> > (otherwise the MSN has to be always present, that is just no
> > point.) Then the key issue is the probability for MSN in the packet.
> 
> LEJ: I was about to say that this is a problem we never had before,
> and that is in some way true. Just because we now might use mechanisms
> to encode the compressed headers in a theoretically optimal way if
> we can guess the right probabilities does not mean it is a big
> problem if that can not be done. 50/50 would always work, or
> optimize for the more efficient case, i.e. when feedback is
> available.

As stated in previous letters, the main problem here is that TCP header
doesn't has a unique identifier like SN in RTP. Using MSN in some
compressed packet can solve it, however, it inevitably introduces
overhead of compressed packet and cannot give exactly feedback as soon
as possible due to the sparse MSN in compressed packet. Moreover,
considering that the decompressor may send feedback with different
frequency, it is hard to determine the probability of MSN in each
packet. A workable 'engineering solution' may not obtain good
efficiency.

As we mentioned in the previous emails, we can also use IP-ID with IPv4
and SEQ or/and ACK with IPv6 as the packet identifier and it is
efficient since the compressor will not add extra data in the compressed
packet and the decompressor infrequently sends feedback in which IP-ID,
SEQ, or ACK are encoded in compressed format. This won't introduce too
much overhead on the feedback channel and will remove the overhead of
MSN in the compressed header. Moreover, it can be achieve good
performance even if the decompressor change the frequency of sending
feedback.

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Thu, 23 May 2002 15:50:46 +0100

Hi all,

Some more feedback on feedback, as it were...

Cheers,

Mark.

> specify how to carry the feedback information.

I don't think that the question of when the decompressor sends feedback 
is any harder than it would be for RFC 3095?  (In fact, I'm convinced 
that it's actually easier if you eliminate mode transitions...)

It is clearly true that we need to specify how to carry the feedback 
information.  However, I don't believe that this should cause us much 
problem.

> packet. A workable 'engineering solution' may not obtain good

Let me address some of these points:

- MSN adds overhead
True, but not much...
(and see later)

- Decompressor cannot give feedback immediately
I don't believe that this is true.  Or rather, that it doesn't always 
matter.  I can always send a negative ack, since in this I need only 
identify the last successfully received MSN.  My belief is that the 
negative ack is the most useful form of 'spontaneous' feedback in this case.
Positive feedback (as noted before) can eliminate sending many copies of 
large compressed packets.  It is up to the compressor (in a sense) to 
make sure that MSNs are available on packets that it would be helpful to 
acknowledge.

- Hard to know the probability for MSN
Agreed.  (Although I don't see what the frequency of feedback from the 
decompressor has to do with this?)
But, as Lars-Erik points out, if we just don't know, 50/50 works!

Thinking about it a bit more, is the situation really this bad?  Rather, 
in what circumstances will we want to make use of sequence numbers?

I would imagine that IR/IR-DYN and the like will always have an MSN. 
For compressed packets, we either specify an arbitrary probability 
(could be 50/50, but probably take account of the fact that we can have 
fairly sparse numbering).  For significant changes, the MSN can be tied 
to this (for example, if a rarely-changing field changes, we can always 
include an MSN).

> performance even if the decompressor change the frequency of sending

I still (personally) have a slightly uneasy feeling that this is even 
more of a fudge than picking an arbitrary probability for an MSN...
The IP-ID in the v4 case makes it workable, but for v6 I just don't 
believe that you can get a (truly) unique identifier for a packet, which 
worries me.

Also, it is going to make some difference to the feedback channel 
utilisation (I think that you're going to have to send a reasonable 
number of bits).

I guess the main question to address is the relative importance of the 
use of bits in the forward and reverse direction.

I probably ought to think about this a bit more...

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)