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

From: [email-masked]
Date: Mon, 15 Dec 2003 12:29:23 -0600

Hi Ghyslain,
Thank you for your attempt for bringing the discussion to a closing. I think you have missed some recent discussion about using byte-wise matched length, using replicate_format_1 for the structure containing IP address compression, IPR status change to non-assertive, etc. I am attempting to fill those points in this summary, so it could reflect latest thoughts and analysis. This would help in bringing closure. 

I also hope that other folks in this email list participate. Considering also the points that were missed and now I have added in this summary.

Best Regards,
Yousuf

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Ghyslain Pelletier
> Sent: Monday, December 15, 2003 6:41 AM
> To: [email-masked]
> Subject: Re: [rohc] IP Address Compression for Context Replication
> 
> 
> 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.
> 

They are not some unrealistic and specific cases. I am answering your comments (sent in your last two emails on this thread) on those cases below:

For mobile router case you wrote:
"From what I understand, only the first connection to each device could
potentially see some benefit in such scenario."

The above is not correct. For every new connection, the IP address compression could save header.  

For BSC to BTS case you wrote:
"How common a case is a statellite link between BSC and Node B???"
The satellite link in the infra-structure of cellular is quite common. I wish I had statistics in front of me to tell you in terms of percentage. I know it is not insignificant.

For a group of devices case you wrote:
"This is not header compression based on the behavior of header fields,
but based on assumptions that are hardly to be expected." 

I don't think it is hard to expect this case. As I have mentioned earlier, that we should define a protocol considering foreseeble future in mind also. Not what we though two years ago as part of TCP field behavior. 

You can call it chasing ghosts. But, if we don't do that, whatever we develop, it would become deficient and archaic soon. I am assuming that by chasing gosts you mean unrealistic cases. Now we really first time started to discuss these cases, could you please elaborate why you think the above cases are unrealistic.

> 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).
>
The IP address compression is part of CR. It is also an optimization of the existing context initialization procedure, just like compression of exact match IP address, partial match TCP ports, etc.
 
> 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.
>   

I think this is where you have missed most of the latest discussion. You are only considering analysis sent by Kristofer, without including the follow-up analysis and development.  The following are the possible cases now:

Case-1: Single Host ; no impact, eplicate_format_0 will be used in this case. The discriminator will indicate a structure without IP address compression. There will be *no additional cost* for single host due to ip_src/dest_addr.discriminator bits. 

Case-2: Multiple Hosts; the discriminator will indicate a structure with IP address compression, e.g. replicate_format_1 as I proposed in this email (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01897.html). There will always be saving if a prefix match is found. A host uses another hosts base context for IP address replication. For "m" new connection, the saving will be  m*(x-matched_len). With half as prefix match. For IPv6, saving is m*60 bits; and for IPv4 saving is m*14 bits. Pick a value of m, if what I have mentiond sounds (...) :). Also, I have chosen byte-wise matched-len as mentioned in this email (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01884.html)

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

I have given the "realistic" cases above and before. As I have mentioned above there is significant saving, without causing any cost to the 1 host 1 server 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.
> 

As mentioned earlier. This was to make the procedure complete. We can drop this.

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

This is answered above.

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

The IP address compression can be added without utilizing any pad and cost of additional bits. I have mentioned this above with repilcate_format_1.

On a separate note, instead of sending some null bits better utilize them for compression. I don't see any disagreement on this point.
 
> 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. 
> 

I see that ROHC-TCP and ROHC-CR drafts are under discussion. I don't think any principle is violated by bringing up "multiple hosts". The "multiple hosts" are valid scenarios, they will become more and more common in near future, and doesn't cost you any bit in the header. I am asking WG to not limit the solutions based on something we thought two years ago, otherwise the solution would be deficient. It is not too late do discuss the CR and TCP-CR. Any comment on this. BTW! The above mentioned field behavior draft has expired. 
 
> > 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?
> 
I think the confusion is you are only considering proxy server address. Zhigang meant hosts addresses.

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

I think the above summary is incorrect. The applicability of IP address compression is significant. Host-m can use IP address of Host-(m-1). The current CR only allows Host-m to use IP address of itself. The IP address compression is allowing it to use this plus context of Host-(m-1). If there are "m" hosts, their IP address can be compressed for every attempt of a new connection. 

n=1 doesn't mean less, it only mean there is only one simultaneous TCP connection between 1 host and 1 server.

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

Your agreement doesn't concur with what Zhigang said. There is a significant benefit for IPv6, and he separted his v4 comment from v6.

> 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.
> 
This has already been answered.
> 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).
> 

I agree with you. Let's support "multiple packet formats". replicate_format_1 with the IP address compression. This has already been discussed earlier in this email. Everyone can implement "IP Address Compression", because the status of IPR has changed(please see my another comment below). So we don't need to implement this as "optional feature".

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

You may have missed the email, where I have announce the IPR status change to non-assertive. The IPR status is "non-assertive". It means no one will be barred from using this IPR and everyone can implement it. Please tell me, how this conflicts with the above requirement.

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

---

From: Ghyslain Pelletier <[email-masked]>
Date: Tue, 16 Dec 2003 16:29:42 +0100

Hi all,

Actually, as the editor for both impacted documents I have been
following this thread rather closely and I do not feel that I have
missed any of the discussions or arguments when writing my previous mail
(http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01899.html).
I am simply trying to filter out statements without substance to bring
up the agreements from my understooding of the list discussion.

I guess I should furhter clarify my previous email regarding IP Address
Compression (IP/AC). I'd invite anyone who's participated to that
discussion so far to validate or invalidate the following summary, in
order to help us move on with some form of consensus.

My feeling is that the following agreements have been roughly reached on
this mailing list regarding IP/AC:

Technical aspects
-----------------
T1) SUFFIX-Match is unrealistic (out);
T2) PREFIX-Match is not possible for last-link context replication. This
    is because the last link means that the compressor/decompressor is 
    co-located with the IP endpoint and will not be routing packets 
    to/from any subnet;
T3) ROHC-CR has been originally motivated for cases when at least one
    IP address was the same - this being the trigger for replication.
    Given this, it makes less sense to attempt to compress differently
    IP address;
T4) Defining a separate packet format for a "feature" does not make the
    "feature" optional - decompressor is still forced to implement it 
    unless some form of negotiation is used or separate profiles;
T5) Any potentially noticeable gain would only occur with IPv6/HTTP1.1 
    (persistent TCP connection), not with IPv4 or HTTP1.0. Persistent
    connections are probably longer-lived and, therefore, the impact of
    any kind of replication is lower, making IP/AC even less 
    significant with respect to IPv6/HTTP1.1;
T6) Any potential gain with IP/AC is not of major significance, also 
    considering that IR-CR is already an optimization of the 
    initialization procedure only (see also NT3).

Non-technical aspects
---------------------
NT1) Motivations for the "field behavior" addressed by ROHC-TCP/CR HC 
     has been extensively discussed and agreed. Addressing a different 
     type of behavior must be properly motivated - just like behaviors 
     currently addressed.
NT2) The fact that some bits are currently used for byte-alignment in 
     the TCP IR-CR packet formats is not a motivation for including 
     IP/AC;
NT3) Applicability of IP/AC (mobile router and satellite links - i.e. 
     not last-link) is limited and not the most expected case;
NT4) A requirement regarding IPRs was agreed by the wg for the TCP 
     solution. I understand the meaning of "non-assertive"
     (as read from http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft
     -saifullah-rohc-ip-addr-comp-context-replicat.txt),
     but the IPR statement still mentions some limitations as to the 
     non-assertivness of the IPR being only valid if other companies do 
     not assert ANY patents against Nokia (even patents not related to
     ROHC);
NT5) The scenarios for motivating the occurence of PREFIX-Match are too 
     weak for including IP/AC in the ROHC-TCP/CR solution;
NT6) Points T6) and NT5) are too weak to make IP/AC a core
     functionality of ROHC-TCP/CR with respect to violating NT4).

Best regards,

/Ghyslain

[email-masked] wrote:
> 
> Hi Ghyslain,
> Thank you for your attempt for bringing the discussion to a closing.
> I think you have missed some recent discussion about using byte-wise
> matched length, using replicate_format_1 for the structure containing
> IP address compression, IPR status change to non-assertive, etc. I am
> attempting to fill those points in this summary, so it could reflect
> latest thoughts and analysis. This would help in bringing closure.
> 
> I also hope that other folks in this email list participate.
> Considering also the points that were missed and now I have added in
> this summary.
> 
> Best Regards,
> Yousuf
> 
Can be found at:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01899.html

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