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

From: "West, Mark (ITN)" <[email-masked]>
Date: Fri, 03 May 2002 17:59:10 +0100

Hi all,

The Uni-/Bi-directional mode thing is turning into quite an interesting 
discussion!

A few thoughts and comments...

One of the key points, raised at Minneapolis, was that it would be nice 
for the modes to work akin to the 'U/O' modes in RFC 3095. 
Specifically, the packet formats remain the same (avoiding the 
complexity of the 'R' mode switch).

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
3/ Make use of TCP/IP header fields to construct an identifier for acks
    (Avoiding any need for explciit identifier)

Option (1) is the original proposal.  The problem with it, as described 
above, is that it makes the mode transition complex.  However, it is the 
most obvious way of distinguishing between the 2 modes.

Option (3) is essentially what Qian and Hongbin have described.  I'll 
comment on this some more later.

Option (2) takes the view that we may as well always make an explicit 
identifier available (avoiding the dual format problem of (1)).  The two 
questions raised by this approach are:
- what is the impact on efficiency?
- is there any point retaining the U/B mode distinction?

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

As to the impact on efficiency, I think that this needs to be related to 
option (3).  Firstly, I would not anticipate having an explicit 
identification in every packet.  There's just no point.  So, we're 
talking about a small number of LSBs in a relatively small subset of the 
packets. If we are thinking about a scenario with no feedback channel, 
though, this is a waste of bits.
The advantage is that the identification is readily available for the 
decompressor to use for an acknowledgement (and is small).  This is what 
we have to weigh against option (3).  With this option there is no need 
for additional information in the forward path, but the acknowledgement 
messages can now become quite large, due to the amount of information 
necessary to build a fairly strong (yet still not unique) identification.

[While thinking about what Qian and Hongbin suggested, I toyed for a 
while with the idea of using some hash over the header as an identifier. 
  However, it appears that this simply adds another possible collision 
to the scenario :-(]

Naturally, I accept the use of the IP ID is a convenient choice for 
IPv4, but having to use the sequence and/or ack number for IPv6 seems 
like a bit of a fudge!
(It's probably worth pointing out that, since acks are likely to be 
sparse, then the 'collision' problem is, perhaps, not a major concern. 
However, it's a lot of data to use on the ack channel, if nothing else...)

I don't really know what the best answer is.  What I *do* know is that I 
agree with the motivation to not have 2 sets of packet formats.  I also 
don't particularly like the idea of using the sequence/ack numbers as 
the basis of an acknowledgement scheme.

Comments welcome...

Cheers,

Mark.

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

---

From: "Qian Zhang" <[email-masked]>
Date: Mon, 13 May 2002 20:34:31 +0800

Hi, Mark
	Comments inline...

Regards,

Qian

> most obvious way of distinguishing between the 2 modes.

Agree. 4-way hand shaking is needed in this option.

> not clear that to me that there is any need to explicitly identify a U

Agree. There is no much difference between U and B modes. The only
difference is that in B mode, we can achieve better performance by
utilizing the feedback from the decompressor side.

> decompressor to use for an acknowledgement (and is small).  

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. I am not
sure whether the probabilities of MSN are the same in both U-mode and
B-mode. If they are different, option (2) has to use the same 4-way
hand-shaking to ensure the compressor and decompressor use the
consistent probabilities set. If they are the same, then there remains a
problem on how to set the proper value for this probability. Too high
probability can cause bad performance in U-mode. Vice versa. Moreover,
even in B-mode, since MSN will not always present in each packet, then
for NACK case, the feedback can not be send out in time. That may cause
some bad performance.

> This is what

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

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 29 May 2002 13:08:46 +0200

As usual, comments inline...

Rgds,
/L-E

>> QZ: 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: 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...)

LEJ: You would at least get rid of one purpose of sending feedback.
Anyway, I agree it should not be harder to resolve than for the RTP
profile.

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

LEJ: How feedback is sent is already covered by the framework part
of RFC 3095, so we only need to define the feedback content and
format for the TCP profile. Thus, I believe Mark is right that this
should not cause us much problem.

>>>> QZ: If option (2) includes MSN in the uniform packet format,
>>>> 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.
>> 
>> QZ: 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.
>
> MW: - 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.

LEJ: To summarize, negative feedback can always be sent, and 
positive feedback would only be useful for packets that the
compressor know it might be good to have the MSN included in. 
This should therefore not be an issue.

> MW: - Hard to know the probability for MSN:
> Agreed. But, as Lars-Erik points out, if we just don't know,
> 50/50 works!
> 
> MW: 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).

LEJ: A combination of these might also work. In any case, I do
not think the cost of MSN will be that significant. At least, I
think the functionality you get is worth the cost.

>> QZ: 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. 
> 
> MW: 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.

LEJ: I tend to have the same kind of uneasy feeling as Mark on
this one, and as mentioned before I do not think the cost of
having an MSN motivates these kind of solutions. I would prefer
to keep a simple and consistent solution.

---

From: "Qian Zhang" <[email-masked]>
Date: Thu, 30 May 2002 17:20:57 +0800

Lars-Erik and Mark,

Please see my comments inline.

Regards,

Qian

> Anyway, I agree it should not be harder to resolve than for the RTP

[QZ:] Maybe I had not expressed myself clearly enough. Yes, we will not
worry about when the decompressor sends feedback. What I want to
emphasize is how to identify packet in the feedback.

In summary, we had discussed two types of approaches for this issue:
1. Add MSN in the forward path, and then put MSN in the feedback packet 
2. Only add certain field(s), which can identify packets, in the
feedback.

I would like to separately discuss the characteristics for each type of
approach.

For the first approach, there are several issues that will decrease the
compression efficiency.
a. The decompressor cannot give feedback immediately (or maybe we should
say that the decompressor cannot give feedback precisely)
For example, if there are 10 packets send out from compressor, 
1 (with MSN) 2 3 4 5 (with MSN) 6 7 8 9 (with MSN) 10. Considering the
cost of MSN, only 1, 5, and 9 packets are send out with MSN. 
If the decompressor finds that the 8th packet had lost, it will send an
NACK packet, however, it can only NACK the 5th packet. In this way, the
compressor can not control the sliding-window efficiently.

b. Hard to give probability for MSN
Yes, we can use the way Mark suggested to control when should add MSN to
a packet. However, there still exists the problem about how to determine
a proper probability, which will in turn affect the compression
efficiency. 

For the second approach, the cost exists only in the backward channel.
For IPv4 case, we can only use IP-ID as identifier for one packet. For
IPv6 case, we can use Seqno+Ackno as identifier for one packet. Only in
the path where TCP send duplicate ACK, there will be some packets have
the same Seqno+Ackno, however, this will not affect the control of the
sliding-window. 

In summary, both these two approaches are not so complicated. The key is
the compression efficiency. 

For both two approaches, I think it is worth that for IPv4 case, just
use IP-ID to identify the packet.

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 30 May 2002 12:48:48 +0200

Qian,

> QZ: 
> I would like to separately discuss the characteristics for 
> each type of approach.
> 
> For the first approach, there are several issues that will 
> decrease the compression efficiency.
> a. The decompressor cannot give feedback immediately (or maybe
>    we should say that the decompressor cannot give feedback
>    precisely). For example, if there are 10 packets send out
>    from compressor. Considering the cost of MSN, only 1, 5,
>    and 9 packets are send out with MSN. If the decompressor
>    finds that the 8th packet had lost, it will send an NACK
>    packet, however, it can only NACK the 5th packet. In this
>    way, the compressor can not control the sliding-window
>    efficiently.

>>> that MSNs are available on packets that it would be helpful to

LEJ: Can you give a detailed example when there will be problems
with this approach? 

> Yes, we can use the way Mark suggested to control when should 
> add MSN to a packet. However, there still exists the problem
> about how to determine a proper probability, which will in turn
> affect the compression efficiency. 

LEJ: The probability only affects the way compressed packet types
are assigned, to encode the most common packet types with fewer
bits. For an MSN, it is indeed difficult to set a value, but it
would still not make a big difference. Note that for TCP, the
compression efficiency target does not have the same priority as
for e.g. RTP compression. I still can not see that the price of
having an MSN is that high.

> QZ: For the second approach, the cost exists only in the backward
> channel.  For IPv4 case, we can only use IP-ID as identifier
> for one packet. For IPv6 case, we can use Seqno+Ackno as
> identifier for one packet. Only in the path where TCP send
> duplicate ACK, there will be some packets have the same
> Seqno+Ackno, however, this will not affect the control of the
> sliding-window. 

LEJ: There are two issues with this:
1) Is Seqno+Ackno a reliable identifier?
   If not, I think we basically will have to find something better.
2) Could we use IP-ID for IPv4?
   If we find a solution for IPv6, that solution could be used also
   for IPv4. I would prefer to have one common approach for both
   IPv4 and IPv6, for simplicity and consistency.

I am still not convinced of the need for an MSN, but have not seen
that strong arguments for not using it either. If another solution
can be found that we can rely on, that might be fine. Anyway, apart
from that, I really think we should have ONE common solution for
both IPv4 and IPv6.

BR
/L-E