Subject: RE: [rohc] context sharing issues on ROHC/TCP

From: "Qian Zhang" <[email-masked]>
Date: Mon, 11 Mar 2002 14:08:31 +0800

Hi Mark,

More comments inline...

Regards,

Qian

> Mark Wrote:
>
> This is a helpful distinction to point out.  Obviously it is useful if
> we can have clear terminology so we all know what we are talking
about...
> 
> I think that "context sharing" is clear.  I understand what you mean
by
> "context reuse", but I think that this might get confused with the
idea
> of re-using a previously used context for a new flow.  What we are
> talking about here, if I understand it, is intitialising a new context
> from an existing one and overwriting certain entries with values from
> the (partial) IR packet?  Perhaps "context replication"?  [although it
> isn't strictly a direct copy]
> 

Agree. Considering the people may take confuse about the term "context
reusing", we can use "context replication" to indicate the case that
initializing a new context from an existing one and overwriting certain
entries by sending PARIAL-IR packet (we can call this procedure as
context updating).

> Mark wrote:
>
> Do you expect that the shareable value will be mutable per packet?
That
> is, are there going to be (say) some fields that are NEVER shared;
some
> that are ALWAYS shared (perhaps); and some that MAY be shared (with a
> flag to indicate this)?

The context replication/updating procedure will take place when each
connection builds its context. The sharable value is mutable for each
connection. For example, suppose there are three connections, which are
able to share their context, delivering data simultaneously. For one
connection, it may be able to share the "Destination Address" field with
the existing context. While for another connection, it may not be able
to share the "Destination Address" fields.

> 
> Also, when you talk about using different encodings, are you thinking
> about doing more than simply choosing whether or not to copy a context
> value from the source context?  I can see that there may be some
> benefits to doing this; but I can also see that this might add
> complexity to the intialisation process.
> It's certainly something to think about, though...
> 

Yes, we can use encoding method to update some fields so as to make the
compression ratio higher.
For example, as people all agreed that for short-lived traffic, this is
an ephemeral port for TCP source port, which increments by a small
amount. Using a simple encoding method based on the original value in
the shared context, we can achieve better results.

We can add the encoding method for those sharable fields by modifying
corresponding profile. So it will not increase the complexity of the
initialization process. However, of cause, it will increase more packet
formats that need to be support in the profile.

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

---

From: "Qian Zhang" <[email-masked]>
Date: Mon, 11 Mar 2002 17:39:14 +0800

Hi Lars-Erik,

Please see my comments inline...

Regards,

Qian

[Qian Wrote] 
> > The state machine part will take care of the context updating, 
> > compressor/decompressor states and modes management. The interaction

> > between state machine and compressed format generation is that the 
> > estimated congestion window or link feedback obtained by state 
> > machine is the control parameter for format generating.
> 
[L-E wrote]
> To use congestion window estimation as a basis for sending an 
> appropriate number of bits for some compressed fields is just one 
> possible implementation strategy (as we discussed and agreed in SLC). 
> This is thus not a normative functionality that should affect the 
> protocol specification.
> 

I want to clarify the roles of congestion window estimation algorithm.
On one hand, congestion window estimation is used to adjust the sliding
window of window-based LSB encoding method so that high compression
efficiency can be achieved without loss the robustness. In this sense,
the congestion window estimation can be regarded as an enhancement
implementation strategy to improve the overall performance in the
compressor side.

However, on the other hand, congestion window estimation is used in
state machine of ROHC-TCP, in which it affects the operation logic of
the compressor in the U-mode.

In the U-mode of ROHC-RTP case, since the feedback from decompressor to
compressor is unavailable or undesirable, transitions between compressor
states are performed only on account of periodic timeouts and
irregularities in the header field change patterns in the compressed
packet stream.

As stated in RFC3095, "Therefore, the compressor MUST periodically
transit to lower compression states.  Periodic transition to the IR
state SHOULD be carried out less often than transition to the FO state.
Two different timeouts SHOULD therefore be used for these transitions."

However, since there exists "implicit feedback" from decompressor to
compressor in TCP behavior, we can adjust sliding window of w-LSB
encoding properly and need not to send refresh packet periodically. We
can also utilize this implicit feedback to control the state transition
and need not transit to lower compression state periodically. 

That is to say, having "implicit feedback" from TCP behavior itself, we
can modify the operation and transition in different states in U-mode to
avoid periodically refresh and transition.

---

From: "Qian Zhang" <[email-masked]>
Date: Mon, 11 Mar 2002 18:00:37 +0800

Hi Mark and Lars-Erik,

Regards,

Qian

> Lars-Erik Jonsson (EPL) wrote:
>  > 1) To me, "context sharing" and "context reuse" have been different
>  >    names for the same thing, and maybe "context replication" is a
>  >    better term. However, we all seem to agree on what we are
talking
>  >    about.
>  >
> 
> Mark wrote:
> "Context sharing" means (essentially) sharing a field between a number
> of contexts.  For example, I have many TCP flows between 2 machines,
> each has a separate TCP context, but all share the same context entry
> for the IP ID.
> 
> "Context replication" (to use my name for it!) is where I initialise a
> new TCP/IP context from an existing one and overwrite some of the
values
> to create the new context.  (This is how I might avoid sending all the
> address and port number information, for example)
> 
> There is a subtle but important difference between initialising one
> context from another (and then allowing them to diverge) and having a
> single value shared by a number of a context entries.
> 
> (To be clear, I tend to view "Context Re-use" as the standard
> ROHC/header compression concept that a context can be re-initialised
to
> support a new flow.  The new flow need bear no relationship to the old
> flow in this case).

Agree. How about we use the terms "context sharing" and "context
replication" from now on to differentiate those two cases?

As we agreed in previous discussion, "context replication" is a more
efficient way since finer granularity sharing can be support.

To me, the control of "context sharing" seems rather complicated.
Considering two connections sharing the same sub-IP context, if two
connections have different compression states, how to handle this case?
If we let both the connection stay in the lower compression state, then
we may loss compression efficiency.

> Lars-Erik Jonsson (EPL) wrote:
>  > 2) I agree with Mark that we should avoid building unnecessary
>  >    complexity. Making good protocols is often about not being too
>  >    inventive. In this case, it might probably be enough if we could
>  >    replicate IP addresses, and maybe port numbers. The requirement
>  >    to improve efficiency for short-lived TCP transfers should then
>  >    be met.
>  >
> 
>  > 3) One important issue to resolve is how to reference field values
>  >    from other contexts. Based on possible solutions for that, we
>  >    can further discuss whether (and in such case how) this should
>  >    work between different profiles.
>  >
>  > 4) I am not sure we should use different profiles when applying
>  >    context replication, that might be messy but I have to think
>  >    more on that.
> 
> Mark wrote:
> I'm still very unclear on this one.  However, I think that a
reasonable
> decision might arise out of considering a simple, effective way to
> handle context sharing/replication.  I don't think that we should be
> aiming to support inter-profile sharing as a definite goal, but if it
> happens...
> (Which, I think, is effectively in agreement with your point 3)
> 

I fully agree that we should provide a simple and effective way to
handle sharing/replication issue. To me, it is not necessary to handle
the inter-profile sharing by now.

However, what I want to emphasize is that we need to consider more about
context sharing/replication besides IP address and port number. Better
performance can be achieved when we consider the TCP options, especially
those used only in SYN packet.

---

From: "Qian Zhang" <[email-masked]>
Date: Mon, 11 Mar 2002 18:13:54 +0800

Glad that we all agree with this issue.

For short-lived connections, sharing the options include Maximum Segment
Size, Window Scale, and SACK-Permitted, which only used in SYN packet,
will significantly improve the performance.

I will update the ROHC-TCP draft to integrate those context
sharing/replication issue that being actively discussed in mailing list.

Regards,

Qian

> -----Original Message-----
> From: West, Mark (ITN) [mailto:[email-masked]]
> Sent: Monday, March 11, 2002 6:09 AM
> To: Dr. Carsten Bormann
> Cc: Lars-Erik Jonsson (EPL); Hongbin Liao (Intl Staffing);
[email-masked]
> Subject: Re: [rohc] context sharing issues on ROHC/TCP
> 
> 
> I keep forgetting TCP options, but you are quite correct!  Lots of
nice
> SYN packet negotiations could be dealt with this way, yes...
> 
> Cheers,
> 
> Mark.
> 
> Dr. Carsten Bormann wrote:
> 
> >>  In this case, it might probably be enough if we could
> >>   replicate IP addresses, and maybe port numbers.
> >>
> >
> > Still catching up with the thread myself, but what about TCP
options?
> > These are getting bulky and are likely to be very compressible in
> initial
> > packets with little effort.
> >
> > Gruesse, Carsten
> >
> 
> 
> --
> 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: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Mon, 11 Mar 2002 11:14:33 +0100

Qian,

> efficient way since finer granularity sharing can be support.

OK, let's use the term "context replication" then, and see if it works
without confusion. We tend to agree that this is probably both simpler
and more useful than "context sharing", so we could focus on that (at
least initially).

> the inter-profile sharing by now. However, what I want to emphasize
> is that we need to consider more about context sharing/replication
> besides IP address and port number. Better performance can be achieved
> when we consider the TCP options, especially those used only in SYN
> packet.

Yes, as Carsten pointed out, this is probably true and I have no 
problem with that. What I wanted to emphasize was just that one should
be aware when to stop optimizing. Just because there is a solution that
can slightly improve performance even more does not mean it is worth
doing.

Rgds,
/L-E

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Mon, 11 Mar 2002 11:31:48 +0100

Hi Qian,

> On one hand, congestion window estimation is used to adjust 
> the sliding window of window-based LSB encoding method so that high
> compression efficiency can be achieved without loss the robustness.
> In this sense, the congestion window estimation can be regarded as
> an enhancement implementation strategy to improve the overall
> performance in the compressor side.

OK, then we tend to have agreement that for Bi-directional operation the
congestion window estimation is only an implementation issue (but may
be a good one worth mentioning in an impl. section of the standard).

> the compressor in the U-mode.

It might be written so today, but is it really necessary to have it as
the basis for Unidirectional operation? 

> state SHOULD be carried out less often than transition to the 
> FO state. Two different timeouts SHOULD therefore be used for these 
> transitions."

There is a significant difference between TCP and UDP/RTP when
considering robustness and error detection. With UDP/RTP, there is no
e2e error recovery, so the compressor MUST periodically transit back
to lower compression state, because it can never know that the
context information has been received by the decompressor. However,
with TCP there is a e2e error recovery that can be used to handle
this, so periodic transition should not be necessary, independent
of if one uses congestion window estimation or not. Both 1144 and
2507 relies on TCP retransmissions for error recovery, and that 
could be a sufficient basis also for the ROHC profile.

> can also utilize this implicit feedback to control the state
> transition and need not transit to lower compression state periodically. 

As said above, we totally agree that the periodic transition is not
needed for TCP, but I can not see how this mandates the use of
congestion window estimation. Would it still not be an implementation
issue, also for Unidirectional operation, since its use only affects the
compressor side and not using it would not make the protocol fail?

BR
/L-E

---

From: "Qian Zhang" <[email-masked]>
Date: Mon, 11 Mar 2002 23:30:06 +0800

Hi Lars-Erik,

Thanks for the comments. Please see my comments inline...

BR,

Qian

> Lars-Erik wrote:

Agree. Even just considering the role for "sending an appropriate number
of bits for some compressed fields", congestion window estimation
algorithm is worth putting in an "implementation section" in the
standard.

> > Qian wrote:
> Lars-Erik wrote:
> considering robustness and error detection. 

Agree.

> Lars-Erik wrote:
> However,

Well. If I had not misunderstood, in this case, if only rely on the e2e
error recovery to re-build the context information, considering the
target long RTT scenario, loss propagation will happened to reduce the
overall performance. 
Meanwhile, if there is any packet loss occurred before the traffic
arrives on the compressor, compressor will transit to the IR state,
which will reduce the performance too.

That is why we planned to use estimated congestion window to alleviate
this effect.

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Mon, 11 Mar 2002 17:06:53 +0100

Qian, 

I think we are talking about different things here. I'll try to
explain what I meant.

> Well. If I had not misunderstood, in this case, if only rely 
> on the e2e error recovery to re-build the context information,
> considering the target long RTT scenario, loss propagation will
> happened to reduce the overall performance. 

We are talking about mechanisms for two different purposes, error 
avoidance (loss-less robustness) and error detection and recovery
(lossy, but "safe"). In ROHC RTP U-mode, the latter is achieved by
having periodic transitions back to lower compression state, and this
is what I referred to above as not necessary for TCP compression since
error recovery will be provided by TCP itself. For error avoidance,
one must make sure enough bits are sent to cope with "possible losses"
and congestion window estimation is one (probably good, but not the
only) way to do this.  

> which will reduce the performance too.

This problem should be avoidable in an implementation.
 
> That is why we planned to use estimated congestion window to alleviate

This might certainly be a good way to get high performance of the TCP
compression scheme, but I still can not see why we should make it
anything more than an implementation choice to use it.

Rgds,
/L-E

---

From: "Qian Zhang" <[email-masked]>
Date: Tue, 12 Mar 2002 22:16:56 +0800

Lars-Erik,

BR,
Qian

> and congestion window estimation is one (probably good, but not the

Agree. In ROHC-TCP scheme, we had used the error detection and recovery
in TCP to avoid the periodic transitions back to lower compression
state. 

However, considering the performance of compression, people should try
to avoid using this error detection/recovery (due to the long RTT fact).
Otherwise, the compressor needs to jump back to the lower state. Then
that is the job needs to be done by the error avoidance. As an
improvement of current TCP compression schemes (RFC1144 and RFC2507),
ROHC-TCP will consider more about the error avoidance issue. As people
agree now, congestion window estimation algorithm can help to achieve
better performance in error avoidance. :-) 
Of course, there may have other approaches to do so, such as use a fixed
sliding window size for the w-LSB encoding. However, it may hard to
decide how to choose a proper value for this sliding window. 

Considering the design guideline for ROHC group (robustness and
efficiency, overall performance better than RFC2507), we may need to
emphasize on error avoidance scheme. So maybe it would be better to put
congestion window estimation as an enhancement, or an option.

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Tue, 12 Mar 2002 15:43:47 +0100

Hi again Qian, I think we are approaching a common understanding. See below.

/L-E

> to avoid using this error detection/recovery (due to the long 

Yes, that is our goal in ROHC, to build in robustness, although error
detection and recovery must always be there as a fall-back, and this is
automatically (implicitly) provided with TCP.

> ROHC-TCP will consider more about the error avoidance issue.

Yes!

> As people agree now, congestion window estimation algorithm can help
> to achieve better performance in error avoidance. :-)

I assume so, but we have not yet seen many convincing arguments in either
direction. If we define a scheme that is not built on the congestion
window estimation mechanism, we will see if other implementations can
be made as efficient as if window estimation is used. At present time, I
believe this might be a good algorithm, but fair comparisons must be
shown to convince me. However, if it is only an implementation issue, 
one do not have to convince others about its strengths, just implement it.

> Of course, there may have other approaches to do so, such as 
> use a fixed sliding window size for the w-LSB encoding. However, it may
> hard to decide how to choose a proper value for this sliding window.

Yes, and an implementer is free to be as inventive as he could to make it
efficient (or choose what is described in the impl. section of the RFC).

> So maybe it would be better to put congestion window estimation as an
> enhancement, or an option. 

My personal opinion is that this is the right way to see it, and let an
implementer choose what mechanisms to use. It has nothing to do with the
protocol, really.