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

From: [email-masked]
Date: Tue, 16 Dec 2003 18:34:59 -0600

Hi Ghyslain,
I am afraid I have to repeat myself a lot in this email. I don't think the summarization are done correctly in your email. Only partial views are presented without considering what Zhigang and I have answered for those views. Even my last email was ignored, which pointed to those earlier discussion. Please tell me why those statements are without substance. Please don't just ignore them, give some argument. Please don't just apply your filter without telling the WG the contents of your filter :)

This is the main point, which you are missing. IP/AC can be added without costing a single bit in replicate_format_0. This can be done by defining replicate_format_1. The "discriminator" field is defined for this purpose and will be used to indicate different formats. The IPR status is "non-assertive", and the IP/AC doesn't need to be optional and it can be implemented as part of CR by any body. If you have a single host (last-link), only replicate_format_0 will be used and there is no overhead. Please see my specific responses below to correctly reflect the agreement/summary. 

Best Regards,
Yousuf

> -----Original Message-----
> From: ext Ghyslain Pelletier [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2003 9:30 AM
> To: Saifullah Yousuf (NRC/Dallas); [email-masked]
> Subject: Re: [rohc] IP Address Compression for Context Replication
> 
> 
> 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

Prefix match is quite possible in other viable scenarios. I have mentioned them before. Why we have to limit our solution to the last-link CR, with one host at the end. We should not limit our solutions based on something we thought two years ago, otherwise the solution would be deficient. We may end up revising the draft soon.  Please add this point.

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

We should try to develop a good solution, considering our latest knowledge and foresight. Why we have to limit ourselves to what we thought originally. Isn't ROHC-CR under development? Make ROHC-CR applicable for multiple hosts also. 

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

This tells me that you have missed some emails on this thread. Please read my emails on this topic. I am not asking you to make the feature optional at all. Implement IP Address Compression on both ends as mandatory feature. The IPR status is changed to "non-assertive", everyone in the world can implement this IPR. We will use separate packet formats to save the cost in terms of bit.

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

This is incorrect I have challenged it in my last email, but you didn't replied. Please do not repeat the above without commenting on the text below. 

If I use replicate_format_0 in the cases of 1 host and 1 server, and I use replicate_format_1 with additional 2 bits needed for the ip_src/dst_addr.discriminator. The gain is with IPv4 and HTTP 1.0 also. Let me explain it again. You are only considering analysis sent by Kristofer, without including the follow-up analysis and development.  Kristofer's analysis considers saving in multiple connections between 1 host and 1 server, considering the cost of the above 2 additional bits. He assumed that we have only one structure, replicate_format_0 and we have to fit this IP addresss compression in the same structure. Later, we realized that we can use two separate structures using "discriminator" bits. If we use separate structures, we don't have additional cost of 2 bits for IP/AC. When we don't have IP/AC, e.g. multiple connections between 1 host and 1 server,  we will use replicate_format_0. When we have IP/AC, e.g. multiple hosts, we will use replicate_format_1. Thus, Kristofer's analysis for cost becomes invalid. 

I think the above is an important point which is being missed.

The following are the possible cases now:

Case-1: Single Host ; no impact, replicate_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. No change for IPv4/v6/HTTP1.0/1.1, everything stays as it is now in the current ROHC-CR and ROHC-TCP draft.

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)

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

My above comments nullifies this conclusion. If you don't agree, please tell me why not.

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

Please see my comment under NT3.

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

IP/AC is not asking to use any byte-alignment bits. Again, you are missing the point and earlier emails from me. I have repeated this above. Please let me know what is not clear in my statements. 

> NT3) Applicability of IP/AC (mobile router and satellite links - i.e. 
>      not last-link) is limited and not the most expected case;

We should not limit our solution for only "one" case, which we thought two years ago during the "field behavior" discussion. We have missed some case at that time, and now we have chance to include them. Why not broaden the solution to these likely cases? Especially, when doing so is not costing a bit for the previously thought case. In fact, it is saving more bits and will make CR more efficient. 

I am not suggesting IP/AC, when the ROHC-CR or ROHC-TCP are frozen for further changes. I am suggesting them while we are discussing and inviting comments on these drafts. I think any hesitation based on our previously set mind should be questionable.

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

The text "(even patents not related to ROHC)" is not on the IPR web-site. It was added by you. I am copying the whole text below for the benefit of others: 

"This is an update to the earlier Nokia IPR disclosure to 
the subject draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt 
(submitted on 2.12.2003).

This is to advise the IETF that Nokia has pending unpublished 
patent application
"Compressing header data" that may relate to the Internet Draft 
submission: IP Address Compression in Context Replication 
(draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt).

Regarding this Internet Draft submission 
draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt, 
to the extent this submission is included into final IETF 
standard spesification, Nokia agrees
not to assert those claims in Nokia patents that apply to this 
submission and are technically necessary to implement the IETF 
standard spesification against any other party in respect of its 
implementation of the specification, provided that the party relying 
on this commitment does not assert its patents against Nokia."

I am not a legal expert, but the above statement read perfectly neutral to me. I would encourage other mailing list participants also to explain to me why the above statement is not neutral.  

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

Please reconsider NT5 and NT6 based on my above comments.

> Best regards,
> /Ghyslain

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 17 Dec 2003 09:00:27 +0100

Hi all,

I'm not going into discussing every point due to lack of time, so I'm just going
to provide my own conclusions of the discussion.

I have to agree with Ghyslains summary of the discussion. I don't think the
arguments for IP/AC have managed to convince people that this will save "enough"
or that it will be "applicable enough". Apart from the authors IP/AC, I haven't
really seen support for it.
And, as Ghyslain points out, even if the IPR is non-assertive, there are
specific conditions placed on it being non-assertive.
Quote from the patent statement:
>>> ...provided that the party relying on this commitment does not assert its
>>> patents against Nokia.
If it is "conditionally non-assertive", then it is not "non-assertive".
Therefore I believe it is still "in violation of" the requirements set by the
WG. I think this is reason enough for not adapting IP/AC.

Just my 2 cents.

Best regards,
	Kristofer Sandlund, Effnet AB

[email-masked] wrote:
> If I use replicate_format_0 in the cases of 1 host and 1 server, and I use replicate_format_1 with additional 2 bits needed for the ip_src/dst_addr.discriminator. The gain is with IPv4 and HTTP 1.0 also. Let me explain it again. You are only considering analysis sent by Kristofer, without including the follow-up analysis and development.  Kristofer's analysis considers saving in multiple connections between 1 host and 1 server, considering the cost of the above 2 additional bits. He assumed that we have only one structure, replicate_format_0 and we have to fit this IP addresss compression in the same structure. Later, we realized that we can use two separate structures using "discriminator" bits. If we use separate structures, we don't have additional cost of 2 bits for IP/AC. When we don't have IP/AC, e.g. multiple connections between 1 host and 1 server,  we will use replicate_format_0. When we have IP/AC, e.g. multiple hosts, we will use replicate_format_1. Thus, Kristof

er's analysis for cost becomes invalid.