Subject: RE: [rohc] IP Address Compression for Context Replication

From: [email-masked]
Date: Fri, 12 Dec 2003 16:35:39 -0600

Hi Lars-Erik and Fredrick,

Please see my response below.

> -----Original Message-----
> From: ext Lars-Erik Jonsson (LU/EAB)
> [mailto:[email-masked]]
> Sent: Friday, December 12, 2003 3:05 AM
> To: Saifullah Yousuf (NRC/Dallas)
> Cc: [email-masked]
> Subject: RE: [rohc] IP Address Compression for Context Replication
> 
> 
> Yousuf,
> 
> Please explain in more detail the scenarios you are addressing,
> so that we can better understand the reason you think this is
> important. At the moment, people do not seem to think this is
> really needed, but we should make sure we do not decide before
> we have all understood the arguments (first then can we have an
> opinion on how to proceed).
> 
> Thanks!
> /L-E
> 

Zhigang has explained the mobile router, which I think is important for consideration. I will explain some other.

Compressed link between two gateways: e.g. in cellular network Base Station Controller and Base Transceiver Station could have a satellite link. In this case we can use IP address compression between multiple hosts.

A group of devices, e.g. bluetooth devices,  forming personal area network, which are connected through a device, e.g. phone, to an external network. It is possible the devices will have  similar IP addresses, so they can be routed through phone. If the compressed link is between  

The above scenarios should help in understanding the need for IP address compression. 

The specs should be designed to efficiently support foreseeable scenarios also, not just the existing ones. 

> -----Original Message-----
> From: ext Lars-Erik Jonsson (LU/EAB)
> [mailto:[email-masked]]
> Sent: Friday, December 12, 2003 3:11 AM
> To: Saifullah Yousuf (NRC/Dallas)
> Cc: [email-masked]
> Subject: RE: [rohc] IP Address Compression for Context Replication
> 
> 
> > I don't see, how we can have multiple replicate_formats.
> 
> Of course there can be different replicate formats.
> 
> > Considering that any optional feature can only be implemented 
> > by different profile. If we define different formats, then 
> > how we are going to tell compressor/decompressor which format 
> > to use.
> 
> The indicator bits gives the format. I do not really understand
> what you mean by "optional feature can only be implemented by
> different profile". That is the case if you have a feature that
> both compressor and decompressor must be allowed to choose
> whether to support or not, but otherwise you can different
> kinds of formats using different compression methoods.
> 
> /L-E
> 
I may have misunderstood. Where is that "indicator bits"? I don't see in rohc-tcp-05. Are you talking about the "discriminator" field?

OK! There are two cases for making a feature optional. One mentioned by you in the above para. The other case is that we make both compressor and decompressor use another replicate_format for the IP Address Compression. In this way, even if the replicate_format_0 does not  have any space for the 2 additional bits of the src/dest IP address discriminator, the new replicate format would have. The advantage is that in  the cases where IP address compression is not needed, there won't be any cost for carrying these two additonal bits. In the cases, where IP address compression is used, it will save much more than 2 bits to justify the cost. We can define replicate_format_1 for IP address compression, if there is no spare bit available in replicate_format_0 (which still need to be seen).

The IPR status is changed to "non-assertive", as I mentioned in an earlier email. Therefore, implementation on both compressor and decompressor should not be a concern. Please consider this point also. 

Thanks,
Yousuf

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

---

From: Ghyslain Pelletier <[email-masked]>
Date: Mon, 15 Dec 2003 13:40:39 +0100

Hi all,

I went through the mail exchanges regarding this topic and here are my
opinions and conclusions. Hopefully this can help bringing the
discussion to a closing.

PREFIX-Match
------------
I agree that a prefix match can occur in some _specific_ cases.

However, this is not a typical scenario and thus my feeling is that
there is no strong motivation to "optimize" ROHC-CR for this
(furthermore with consideration that CR itself is already an
optimization of the existing context initialization procedure).

From the discussions, it seems that in the case of:
- IPv4 with either HTTP1.0 or HTTP1.1, it has been agreed that there 
  would be no significant gain to include IP address compression;
- IPv6 with HTTP1.0 (multiple TCP connections), the potential gain would 
   be very small, if any;
- IPv6 with HTTP1.1 (persistent TCP connection), there could be some 
  gain - however in such case we are talking about the initialization of 
  a single connection, and the 2-3 first packets (IR-CR). However the 
  (lack of) applicability of IP address compression (see a later point 
  in this mail) makes this potential gain negligible in my opinion.
  
Therefore, before even considering how many bits we could save _when_
this would occur, I am much more interested in knowing how frequently
PREFIX-matching can *realistically* occur. My opinion is that this is a
very marginal case.

SUFFIX-Match
------------
[email-masked] wrote:
> I honestly don't know how often "suffix match" will occur,
> but think it's something useful to plan in protocol. 

I strongly doubt that a suffix match (e.g. part or all of the interface
ID) will occur in any scenario, other than due to pure coincidence. I
don't think we should design compression on such basis.

EXACT-match
-----------
I believe that this will be the most common scenario for replicating one
or both IP addresses. This is the scenario addressed by ROHC-CR.

Overhead
--------
Some discriminators in the current IR-CR packets are currently longer
than necessary. This is in order to make the packet formats
byte-aligned. As the packet formats will soon be updated, there is no
guarantee that these bits will still be padding bits. This is thus not
an argument for adding IP address compression if the gain is not worth
it.

Gains
-----
[email-masked] wrote:
> We are totally ignoring another dimension of multiple hosts.
> In your equations we are only comparing n flows between 1
> host and 1 server. If we have m multiple hosts in the system
> with compressible IP addresses. The saving will be 55*m bits
> for HTTP 1.1./IPv6. The theoretical value of m could be 2^64,
> but we can reasonably pick a value in multiples of tens of
> thousands. Let's say if we pick, 10,000.

<draft-ietf-rohc-tcp-field-behavior-xx.txt> has been a working group
document since March 2002. This is where the type of field behavior to
be addressed by TCP header compression has been discussed extensively. 

Section 6.5 specifically and clearly states that for short-lived flows
(i.e. the problem space for context replication), what is to be
considered is multiple TCP connections between the same pair of hosts.
So it is no surprise that this is the focus of ROHC-CR.

The case of "multiple hosts", would it be of any relevance at all, must
be discussed and agreed by the working group before we can consider it
an argument and so far I cannot see a strong case for it. 

> This would give a saving of 550,000 bits.

(...). 

[email-masked] wrote:
> My point is that multiple host scenario is not uncommon to
> ignore. We should not limit the HC in the way you mentioned
> below. Moreover, the decision should be made based on cost
> vs. gain analysis. Again over here also we should not limit
> to HTTP 1.0 and IPv4.

Not including IP Address compression does not limit the HC in any way.
Please keep some context regarding the very limited applicability of
this proposal. IPv4 or IPv6 flows using either HTTP1.0 or HTTP1.1 can
still use context replication efficiently in the most expected cases.
Regarding cost vs. gain analysis - I agree! - and see also my next
comment on applicability and the last section of this mail where I add
"based on agreed requirements" as well...

Applicability/Scenarios
-----------------------
[email-masked] wrote:
> This brings another simple example: HTTP 1.1 proxy server,
> regardless if the origin server supports HTTP 1.1. A proxy
> server is quite typical configuration for a subnet.

I am quite confused here - isn't this also speaking in favor of
EXACT-match of the IP address as the most commonly expected scenario,
thus defeating the argument in itself?

[email-masked] wrote:
> First, I don't think n=50 (i.e. 50 simultaneous TCP connections)
> is realistic. 
>
> Second, the whole purpose or usefulness of TCP/IP HC is to
> reduce header overhead. Then, why would a client open many TCP
> connections to the same server and thus introduce extra header
> overhead/context, instead of using one persistant connection?
> It would look to me like creating problems and then solving it.
> It doen't make sense to me.

I agree! It is much smarter to use persistent connections. When doing
so, the number of new contexts to be initialized is less, thus much
fewer IR-CR would be sent and thus optimizing the cases where n=1 is of
little significance. In my opinion this means that the applicability of
IP Address compression is now even less motivated.

[email-masked] wrote:
> I don't know what is the current distribution between HTTP
> 1.0 and 1.1. But based on my knowledge, HTTP 1.1 used more
> and more to optimize performance. And for the simple reasons
> I gave above, it doesn't make sense to me to implement TCP/IP
> HC without eliminating the root of problems: too many TCP
> connections incurred by HTTP 1.0.

I think that it makes more sense for ROHC-CR to be particularly
well-suited for when that specific "problem" is occurring. And the most
commonly expected case is still when EXACT-match of the IP address
occurs anyway.

[email-masked] wrote:
> As to IPv6 vs v4, my guess is that IPv4 will stay for
> sometime. But IPv6 will pick up, at least that is what I
> heard here in IETF and some other standardization
> orgonaizations. Regardless of what is current situaiton,
> a viable TCP/IP HC protocol should have a good handle of
> IPv6. As to IPv4, IP address compression still brings
> benifigs, though small.

I believe ROHC-TCP is viable by itself. ROHC-CR is an optimization for
ROHC-TCP that is also applicable to other profiles, and it is
particularly welcome for the TCP profile. Context replication targets
the initialization procedure, so keep in mind that we are talking about
2-3 initial packets in most cases, not an optimization of the entire
compressed flow. Therefore I agree with you - IP address compression
bring only small benefits - and I will conclude also that this is not
often applicable and when so, only for a small number of packets within
the header compressed flow.

Finally, I must say that I fail to understand from the proponents of
this solution a clear, realistic and useful scenario with a significant
gain.

Optional features
-----------------
[email-masked] wrote:
> I don't see, how we can have multiple replicate_formats. Considering
> that any optional feature can only be implemented by different
> profile. If we define different formats, then how we are going to

Defining different formats and defining which ones are used is not a
problem - multiple packet formats must however all be supported by at
least the decompressor, therefore "multiple packet formats" is no
equivalent to "optional feature".

For a feature to be optional, it must be possible for a decompressor not
to implement it without possibility for the compressor to use the
feature, thus implying some form of beforehand negotiation (which could
take the form of the definition of different profiles, one supporting
the feature - the other not).

ROHC-TCP/CR requirements
------------------------
Finally, and certainly not least, I'd like to remind that a requirement
has been explicitly _stated_, _motivated_ and *agreed* by the working
group in terms of IPRs with relation to ROHC-TCP and ROHC-CR, from
draft-ietf-rohc-tcp-requirements-06.txt - section 2.5 - "Requirements on
ROHC TCP/IP Header Compression".

(I am copy-pasting it here for everyone's convenience)

http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-requirements-06.txt

 2.5.  Intellectual Property Rights (IPR)

   The ROHC WG must spend effort to achieve a high degree of
   confidence that there is no IPR covering a final compression
   solution for TCP.

   Justification: Currently there is no TCP header compression
   scheme available that can efficiently compress the packet headers
   of modern TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill
   this gap by providing a ROHC TCP scheme that is applicable in the
   wide area Internet, not only over error-prone radio links. It
   must thus attempt to be as future-proof as possible, and only
   unencumbered solutions will be acceptable to the Internet at
   large.

This section has been present since
<draft-ietf-rohc-tcp-requirements-01.txt> from June 20, 2001, where it
was agreed and included by the WG. To not meet it requires a
particularly strong case, which is not true for IP address compression.
 
My opinion/conclusions
----------------------
It is my opinion, and this in addition to the technical discussions that
I have seen so far regarding this on the mailing list, that IP Address
compression is *very* marginal in terms of:

1) potential compression gain
2) applicability
  (e.g. _when_ it can be used to some gain).

It thus seems clear that it cannot be considered as a "core"
functionality _required_ for ROHC-CR, and therefore I support the many
who have so far expressed objections and motivations against including
this.

This would also violate a requirement specifically agreed by the wg with
a rather weak technical case for doing so.

Hopefully this can help closing this discussion.

Best regards,

/Ghyslain

-- 
Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegränd 11
Box 920, S-97128 Luleå, SWEDEN
Phone : +46 (0) 920 20 24 32 
Mobile: +46 (0) 706 09 27 73
[email-masked]
http://www.ericsson.com

I have a new mail address: [email-masked]
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

---

From: Ghyslain Pelletier <[email-masked]>
Date: Mon, 15 Dec 2003 13:42:21 +0100

See more included comments

Best regards,

/Ghyslain

[email-masked] wrote:
> Zhigang has explained the mobile router, which I think is important
> for consideration. I will explain some other.
> 
> Compressed link between two gateways: e.g. in cellular network Base
> Station Controller and Base Transceiver Station could have a satellite
> link. In this case we can use IP address compression between multiple
> hosts.

How common a case is a statellite link between BSC and Node B???
 
> A group of devices, e.g. bluetooth devices,  forming personal area
> network, which are connected through a device, e.g. phone, to an
> external network. It is possible the devices will have  similar IP
> addresses, so they can be routed through phone. If the compressed link > is between

This is not header compression based on the behavior of header fields,
but based on assumptions that are hardly to be expected.
 
> The above scenarios should help in understanding the need for IP

(...)
 
> The specs should be designed to efficiently support foreseeable
> scenarios also, not just the existing ones.

I feel we are chasing ghosts here. My impression is that this is a
solution looking for a problem. See also further comments later in this
mail about why I have this impression. 
 
> I may have misunderstood. Where is that "indicator bits"? I don't see
> in rohc-tcp-05. Are you talking about the "discriminator" field?
> 
> OK! There are two cases for making a feature optional. One mentioned
> by you in the above para. The other case is that we make both
> compressor and decompressor use another replicate_format for the IP
> Address Compression. In this way, even if the replicate_format_0 does
> not  have any space for the 2 additional bits of the src/dest IP
> address discriminator, the new replicate format would have. The
> advantage is that in  the cases where IP address compression is not
> needed, there won't be any cost for carrying these two additonal bits.
> In the cases, where IP address compression is used, it will save much
> more than 2 bits to justify the cost. We can define replicate_format_1
> for IP address compression, if there is no spare bit available in
> replicate_format_0 (which still need to be seen).

See my previous mail under "Optional features".
 
> The IPR status is changed to "non-assertive", as I mentioned in an
> earlier email. Therefore, implementation on both compressor and
> decompressor should not be a concern. Please consider this point also.

I am no lawyer, but an IPR is an IPR - and this issue still concerns me.
See also my previous mail under "ROHC-TCP/CR Requirements"