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

From: Kristofer Sandlund <[email-masked]>
Date: Mon, 01 Dec 2003 08:23:21 +0100

Hi all,

I don't think it would be a good thing to add this to the Context replication, 
since it is a very small optimization, cannot be made optional and is 
IPR-encumbered.

BR,
	Kristofer Sandlund, Effnet AB

Lars-Erik Jonsson (LU/EAB) wrote:
> One observation on the non-technical issue...
> 
> 
>>>However, more seriously, I note that the draft has an IPR 
>>>statement :-(
>>>
>>>We are trying to make the TCP compression solution as 
>>>generally useful as possible and so the inclusion of an
>>>encumbered concept is something that I, personally, would
>>>object to.  Can you clarify this position?
>>>
>>
>>Our IPR folks are sending an IPR disclosure related to this 
>>draft with more information on the following web-page:
>>http://www.ietf.org/ipr. 
>>
>>Once that information is available, the WG can look into the 
>>information and can see that it satisfy the needs for 
>>generally useful.
>>
>>I would like to say that the proposed IP address compression 
>>could be an additional optional feature on top of basic 
>>context replication. As an optional feature, it should not 
>>have concern as an encumber concept.
> 
> 
> The only way we can have optional features that would not
> have to be implemented would be by having multiple profiles,
> as that is our way of providing negotiation of supported 
> functionality. 
> 
> As a general technical comment, I think there are many small
> optimizations we could do with context replication, but that
> does not mean it is a good idea to do it.
> 
> /L-E 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc

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

---

From: [email-masked]
Date: Tue, 2 Dec 2003 11:02:10 -0600

Hi Kristofer and Lars-Erik,
Thank you for your comments. I have answered your emails together below. 

Regards,
Yousuf

> -----Original Message-----
> From: ext Kristofer Sandlund [mailto:[email-masked]]
> Sent: Monday, December 01, 2003 1:23 AM
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: Saifullah Yousuf (NRC/Dallas); [email-masked]; 
> [email-masked]
> Subject: Re: [rohc] IP Address Compression for Context Replication
> 
> 
> Hi all,
> 
Having same prefix in IP addresses, both in IPv4 and IPv6, is quite common and should be exploited for more compression. 

Let's take the first objection, "a very small optimization". This is not a small optimization. An IPv6 address is composed of 16 bytes, and there is a potential of saving many bytes from both source and destination addresses. If we assume that the subnet prefix is 64 bits, then it has potential of saving 8 bytes from an IP address. 8 byte saving is not a small optimization, if we consider 40 bytes of the total IPv6 header, then it is 20% saving on the raw IP header. If we consider TCP and IP header (60 bytes) it still gives 13.33% saving. 

Also, I have mentioned in my reply to Mark that this case is quite frequent to consider, I am repeating myself here with one more example:
- One case is mobile router, e.g. a train connected through a mobile router to an external network. In this case the IP addresses can be temporally close.
- Another case is Personal Area Network, e.g. a person carrying a group of bluetooth devices which are connected via a mobile phone to an external network. In this case also the IP addresses will be temporally close. 
- Some networks, e.g. cellular, have IP terminals with same prefix indicating their gateways for their external networks.
- Corporate LAN environment has hosts with same prefix. In fact, any gateway based network would have same prefix for the hosts in its subnetwork. 

Let's take the second objection, "cannot be made optional". I think this objection stem from the fact that the IP address compression solution is IPR-encumbered, the third objection in your email. Otherwise, if IP address compression improves compression we don't care it is optional or mandatory. I have talked to my IPR folks about this objection, and they agree that everyone should get licenses of the relevent IPR(s) on reasonable and non-discriminatory (RAND) terms. The official statement should appear on www.ietf.org/ipr soon, and I am also announcing it on the mailing list to continue the discussion. I hope this would take away the IPR concern. I have expanded further on the optional/mandatory comment in my next comment. 

> > as that is our way of providing negotiation of supported 

Considering that everyone can implement the IP address compression on RAND terms, I propose to have this as mandatory part of context replication. I am borrowing the structure from Page 32 of http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt to show the proposed changes in the replication format: 

replicate_format_0  ::=       . . .
	                      ip_src_addr.discriminator,      %  2 bits
                            ip_dst_addr.discriminator,      %  2 bits
                           	. . .
                            ip_src_addr,                    %  0 to 32 bits as indicated by ip_src_addr.discriminator
                            ip_dst_addr,                    %  0 to 32 bits as indicated by ip_dst_addr.discriminator
                           	. . .

The discriminator will indicate no match, full match, prefix match and suffix match. The discriminator will be similiar to the existing src/dest port numbers discriminator in the replicate_format_0 structure, which also indicates more than two sizes of port number values. If we can allow port numbers to have compressed value, then I think we should also allow IP addresses to have compressed values.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 3 Dec 2003 15:53:55 +0100

> Let's take the second objection, "cannot be made optional". I 
> think this objection stem from the fact that the IP address 
> compression solution is IPR-encumbered, the third objection 
> in your email. 

Actually, my comment was an answer to your proposal to make this
an optional feature in context replication, where I noted how
such an optional feature would have to be added, i.e. it would
require an alternative profile. 

> I any case, Otherwise, if IP address compression improves 
> compression we don't care it is optional or mandatory. I have 
> talked to my IPR folks about this objection, and they agree 
> that everyone should get licenses of the relevent IPR(s) on 
> reasonable and non-discriminatory (RAND) terms. The official 
> statement should appear on www.ietf.org/ipr soon, and I am 
> also announcing it on the mailing list to continue the 
> discussion. I hope this would take away the IPR concern. 

Probably not. RAND-terms is usually not considered sufficient
if an "IPR-free" solution is required.

> Considering that everyone can implement the IP address 
> compression on RAND terms, I propose to have this as 
> mandatory part of context replication. I am borrowing the 

This is not true, and answers so far have been rather
skeptical to the idea, both because of the IPR and for
technical reasons.

/L-E

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 5 Dec 2003 16:53:13 +0100

> For IPR reason, I have an update please see the last para of 
> this email. For technical reasons, allow me to disagree. I 
> still have to see an argument that this is not a good 
> technical solution. 

It might be useful in some cases, but there always a trade-off.
How much do you gain, in what cases, and how often are these
cases expected to happen. Further, are there other mechanisms
that will help is these cases.

As also noted in Kristofers mail, the cases when this will
have positive impact are not that many, and considering that
we already have context replication reduces the relative gain
even more. We have tried to make context replication simple,
and for that reason I think this proposal is not important
enough.

The IPR is of course also an important factor.

/L-E

---

From: [email-masked]
Date: Fri, 5 Dec 2003 16:21:36 -0500

One small correction (sorry about this):

> Now let's compare that to the handling of TCP source port in tcp-05 I-D. The
> cost = 2*n bits, the gain = 8*n bits ==> benefit/cost ratio = 4.

The gain should be 8*(n-1) ==> benefit/cost ratio = 4*(n-1)/n.

BR,
Zhigang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
[email-masked]
Sent: December 05, 2003 03:00 PM
To: [email-masked]; Saifullah Yousuf (NRC/Dallas)
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [rohc] IP Address Compression for Context Replication

Hi Kristofer,

I'd like to throw in some comments if I may.

You've raised a valid question: what would be the gain and cost?
I'll try to answer that in different cases below.

The first case, as you mentioned below, is that the a client opens
multiple TCP connections from the same source IP address to the same
server (i.e. dst address). Even in this case, our proposal allows the 
compression of the IP addresses of the first connection, since the
IP addresses within the same subnet have same prefix. Assuming IPv6
and n multiple TCP connections, the cost = 1*n bits (for the src IP address)
the gain = 64 bits. So the benefit/cost ratio = 64/n. 

(Note I've already made conservative estimate about the gain, since the 
prefix mathcing of IP address could be much longer than 64 bits in practice.)

Now let's compare that to the handling of TCP source port in tcp-05 I-D. The
cost = 2*n bits, the gain = 8*n bits ==> benefit/cost ratio = 4. Compare
this to the above, I don't see our prosal is a "small optimization" even 
assuming we have 16 multiple connections between the same (source IP, dest IP).

Futhermore, for HTTP 1.1, a client SHOULD implement persistent connections.
That means n should be closer to 1, if not equal. So, the benefit/cost ratio
of our proposal is much larger than those already exists in tcp-05. 

There are also other usage cases. For example, due to security/privacy reasons, 
a client may want to use different IP addresses to connect to servers (even 
the same one). 

Lastly, note that our proposal is not only aimed at TCP HC. It can be used
as a general way to share context between packet flows within a subnet.
In one extreme case for IPv6, a rounter can even just use one context to
compress addresses for all the nodes within the subnet. That simplifies
the logic and reduces CPU/memory cost, while focusing on the biggest
part of IPv6 header (32 out of 40 bytes).

BR,
Zhigang

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Kristofer Sandlund
> Sent: December 05, 2003 01:58 AM
> To: Saifullah Yousuf (NRC/Dallas)
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Hi Yousuf!
> Sorry for not explaining clearly what I meant with my earlier 
> answer. Here is a 
> more detailed explanation:
> 
> Regarding "small optimization", I agree that it is not minor 
> if you save 20% off 
> every header, but the question is how often this will occur 
> without you already 
> having a more suitable context to replicate from (i.e. one 
> with an exact match).
> The context-replication-01 seems to target situations where 
> you are opening 
> multiple TCP connections from the same host, to the same 
> server (such as web 
> browsing). For this case, you will for all but the first flow 
> get an exact match 
> for at least one of the addresses (most often both). If you 
> expect a lot of 
> temporally close connections like this, then your savings 
> will be a lot smaller.
> 
> Note: We _could_ also take into account that you're using one 
> extra bit of 
> discriminator per address (i.e. 2 bits per  packet per IP 
> header). This will 
> have a negative impact on compression if we have a very high 
> percentage of exact 
> matches and very seldom have partial matches.
> 
> So my question would be: How many separate TCP connections do 
> we expect the 
> average user to open up in a short timespan? 1, 10, 100?
> When I have an _idea_ of that number, I will be able to say 
> if your proposal 
> makes sense technically. Right now, I can't really say.
> 
> 
> On the IPR issue, I would not like us to add IPR:ed solutions 
> unless it is a 
> really large gain, but let's wait and see what your IPR 
> people say before we 
> take that discussion further.
> 
> Best regards,
> [email-masked] wrote:
> > Hi Lars-Erik,
> > 
> > Thank you for your reply. 
> > 
> > 
> > For IPR reason, I have an update please see the last para 
> of this email. For technical reasons, allow me to disagree. I 
> technical solution. In the emails by Mark and Kristofer, the 
> concern was raised without any argument that why it is not a 
> good technical solution. I gave the technical 
> reasons/advantages, but I didn't see any response back. I am 
> repeating here again, I would appreciate if someone could 
> comment on the following and tell me why we are skeptical 
> about savings from IP address compression 
> (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt):
> > 
> > Having same prefix in IP addresses, both in IPv4 and IPv6, 
> is quite common and should be exploited for more compression. 
> > 
> > Let's take the first objection, "a very small 
> optimization". This is not a small optimization. An IPv6 
> address is composed of 16 bytes, and there is a potential of 
> saving many bytes from both source and destination addresses. 
> If we assume that the subnet prefix is 64 bits, then it has 
> potential of saving 8 bytes from an IP address. 8 byte saving 
> is not a small optimization, if we consider 40 bytes of the 
> total IPv6 header, then it is 20% saving on the raw IP 
> header. If we consider TCP and IP header (60 bytes) it still 
> gives 13.33% saving. 
> > 
> > Also, I have mentioned in my reply to Mark that this case 
> is quite frequent to consider, I am repeating myself here 
> with one more example:
> > - One case is mobile router, e.g. a train connected through 
> a mobile router to an external network. In this case the IP 
> addresses can be temporally close.
> > - Another case is Personal Area Network, e.g. a person 
> carrying a group of bluetooth devices which are connected via 
> a mobile phone to an external network. In this case also the 
> IP addresses will be temporally close. 
> > - Some networks, e.g. cellular, have IP terminals with same 
> prefix indicating their gateways for their external networks.
> > - Corporate LAN environment has hosts with same prefix. In 
> fact, any gateway based network would have same prefix for 
> the hosts in its subnetwork. 
> > 
> > 
> > 
> > I have communicated the WG concern to my IPR folks that 
> RAND-terms is not sufficient. They should be giving us more 
> information soon. In the mean time, I would request to the WG 
> to evaluate the IP address compression proposal technically. 
> If technically it is found worthy of adoptation, but not 
> found "IPR-free" we can drop the idea. But, if it also 
> satisfies the IPR-free concern, then why not adopt it. It 
> would provide more saving.  
> > 
> > Regards,
> > Yousuf
> >

---

From: [email-masked]
Date: Fri, 5 Dec 2003 15:42:50 -0600

Hi Lars-Erik,
Thanks for the reply. Zhigang has given a good analysis of how much we can gain. He also compared with the port # compression, which also has two bits of discriminator. I think 2 bits of IP address discriminator are more justified than the port #s. I don't think there are other mechanisms for providing IP address compression in context replication. 

Kristofer compared with the case where one host has multiple TCP connection with the same server (web browsing). I disagree that we should target context replication for the cases where one host creates multiple TCP connection with the same server. First, this is not a frequent case with HTTP 1.1, they provide persistent TCP connection. Second, IP Address compression is not limited to TCP and it could be applied to the other profiles supporting context replication. If I compare the Kristofer case with the cases I have mentioned, my cases are more frequent. 

Could you please clarify why it is not simple technically. We are only matching run length for IP address compression.

Thanks,
Yousuf 

> From: ext Lars-Erik Jonsson (LU/EAB)
> [mailto:[email-masked]]
> Sent: Friday, December 05, 2003 9:53 AM
> Cc: [email-masked]

---

From: [email-masked]
Date: Fri, 5 Dec 2003 15:47:05 -0600

Hi Kristofer,
I would like to answer the question in your email. For the comments regarding other parts of your email, please see the last two emails on this subject.

Thanks,
Yousuf

> Sent: Friday, December 05, 2003 1:58 AM

If you are asking TCP connection between one user and one server, then the answer is 1 with HTTP 1.1.

---

From: "Qian Zhang \(MSR\)" <[email-masked]>
Date: Sun, 7 Dec 2003 11:18:14 +0800

Hi all,
 
I agree with Lars-Erik's comments in his previous email, yes, we can have many possible enhancements for context replication part, however, it does not make lots of sense to add all them in.
We should keep in mind that we need very careful when using context replication technology. We need to make sure that the base context is reliable enough before it can be reused. Thus, some simple and efficient scheme is good enough for it. 
It would make the ROHC-TCP profile too complicated if we introduce another optinal for it. 
Moreover, IPR issue is a big concern. Just to refresh everyone's memory, the uni-directional enhancement technology had been removed from the basic ROHC-TCP profile although it can bring much performance gain in uni-directional scenario.
 
Best,
Qian

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Sat 12/6/2003 5:47 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [rohc] IP Address Compression for Context Replication

Hi Kristofer,

Thanks,
Yousuf

---

From: [email-masked]
Date: Mon, 8 Dec 2003 09:09:25 -0600

Hi Qian,
Thank you for your comments. I would also like to give an update that the IPR status is changed to "non-assertive". An official statement will appear soon. With this status Nokia is not going to assert its IPR and anybody can implement it. Hopefully this would take away the IPR concern.

Please see my specific replies below. Please also comment on the emails sent by me and Zhigang on Friday (USA time).

Regards,
Yousuf 

> From: ext Qian Zhang (MSR) [mailto:[email-masked]]
> Sent: Saturday, December 06, 2003 9:18 PM
> To: Saifullah Yousuf (NRC/Dallas); [email-masked]
> I agree with Lars-Erik's comments in his previous email, yes, 
> we can have many possible enhancements for context 
> replication part, however, it does not make lots of sense to 
> add all them in.

I also agree with you and Lars-Erik that we should add only those enhancements which make sense. Zhigang has provided numbers to show the savings in an email sent on last Friday. Please tell me why technically it doesn't make sense to have IP address compression for CR? I was asked to give cases and gain, and we have provided that. Kristofer compared it with one host and one server TCP connections, and we replied it. We should make decision on the basis of technical argument. 

> We should keep in mind that we need very careful when using 
> context replication technology. We need to make sure that the 
> base context is reliable enough before it can be reused. 
> Thus, some simple and efficient scheme is good enough for it. 

I don't think that the IP Address compression for CR has any issue with the reliability of the base. Could you please identify if you see any. I have mentioned in an earlier email that how simple our proposal is. We are only matching run length. Could you please support your above statement with technical reasons why it is not simple and not efficient.

> Moreover, IPR issue is a big concern. Just to refresh 
> everyone's memory, the uni-directional enhancement technology 
> had been removed from the basic ROHC-TCP profile although it 
> can bring much performance gain in uni-directional scenario.
>  

I had understood the IPR concern, and had communicated it to the IPR folks. They have changed the IPR status to "non-assertive". 

> I would like to answer the question in your email. For the 
> comments regarding other parts of your email, please see the 
> last two emails on this subject.
> 
> Thanks,
> Yousuf
> 
> If you are asking TCP connection between one user and one 
> server, then the answer is 1 with HTTP 1.1.
> 
> >

---

From: [email-masked]
Date: Tue, 9 Dec 2003 11:06:17 -0600

Hi Kristofer,
Thank you for your detailed analysis. Please read my comments below. 

Regards,
Yousuf

> Sent: Tuesday, December 09, 2003 4:35 AM
> To: Liu Zhigang.C (NRC/Dallas)
> Cc: Saifullah Yousuf (NRC/Dallas); [email-masked];
> [email-masked]; [email-masked]
> Hi Zhigang,
> I took out some of your comments into this mail that I don't 
> fully agree with 
> you, I hope I do not mis-quote you.
> 
> Zhigang> Assuming IPv6 and n multiple TCP connections, the 
> cost = 1*n bits (for
> Zhigang> the src IP address) the gain = 64 bits. So the 
> benefit/cost ratio =
> Zhigang> 64/n.
> 
> Maybe I've misunderstood you, but don't you have to take into 
> account  the 
> "matched-len" field from your draft as well? Also, you will 
> have a 2*n-bit 
> discriminator overhead, since both addresses will have 1 bit extra of 
> discriminator even if only one of them is subject to "partial match".
> For a x-bit prefix match on one of the addresses, I think the 
> gain/flow ratio 
> should be (n is the number of multiple TCP connections as in 
> your mail):
> 
> (x - matched_len_width - n * 2) / n

You are right the matched_len_width should be considered. 

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. This would give a saving of 550,000 bits.

We are also ignoring the spare bits available due to byte alignment. If we have 2 spare bits in the structure, then this n*2 will not be in the equation. The equation will be

(x - matched_len_width)/n

Now let's see where we can get these 2 spare bits. I see in rohc-tcp-05 that replicate_format_0 is defined for IPv4 only and discriminator has 4 bits. Although, only one value is defined. If this is to fill up the rest of the available bits, then we can easily borrow 2 bits from there. Could anyone tell why do we have 4 bits of discriminator and one value?

For IPv6, I'll comment when I see the structure as it is not present in the rohc-tcp-05 draft. I can guess that the spare bits will be available in that structure. IPv6 has fewer fields for discriminator and flags compared to IPv4.
 
> 
> This I feel gives a fair comparison against the current 
> replication scheme.
> 
> With this formula and a 64-bit IPv6 prefix match on the 
> source address (full 
> match on dest), we get:
> 
>      (64 - 7 - n*2) / n = (57 - 2*n) / n
> 
> Gain examples IPv6, 64 bit dst match:
> (HTTP 1.1)    n=1  => 55    bits/replicated flow
> (HTTP 1.0)    n=10 =>  3.5  bits/replicated flow
> (HTTP 1.0)    n=50 => -0.86 bits/replicated flow
> 

If we use two spare bits, all of the above values will be the same irrespective of HTTP version, i.e. 55*m bits over multiple hosts and 55 bits/replicated flow for 1 host. Similarly, for IPv4 it will all be 15*m bits. 

One other point, I think that n=50 is totally unrealistic. I would also question n=10. I only have HTTP 1.1 available in my browsers, so I won't be able to verify what should be a realistic n for HTTP 1.0. 

I would also suggest to evaluate the cost and gain for the TCP port #s and use bits with maximum gain. Since, we are still discussing rohc-tcp draft. TCP port  #s are also using 2*n bits more for indicating port # compression. If we use the same formula for the TCP port #s, which has 2 bits for src and dest port discriminator. The  8 bit source and 8 bit destination port matches results into the following formula, with the same analysis as yours:

(16 - n*2) / n

Gain examples for the port #s:
(HTTP 1.1)    n=1  => 14    bits/replicated flow
(HTTP 1.0)    n=10 => -0.4  bits/replicated flow
(HTTP 1.0)    n=50 => -1.68 bits/replicated flow

The above clearly shows that the overall IP address gain is better with the 2 bits cost compared with the TCP port #s. I would rather have 2 bits discriminator for the IP addresses then the TCP port #s. Please also consider this point. 

> And for a 16-bit IPv4:
> 
>      (16 - 5 - n*2) / n = (11 - 2*n) / n
> 
> Gain examples IPv4, 16 bit dst match:
> (HTTP 1.1)    n=1  =>  9    bits/flow
> (HTTP 1.0)    n=10 => -0.9  bits/flow
> (HTTP 1.0)    n=50 => -1.78 bits/flow
> 
> So, my conclusion would have to be that there will be a large 
> gain for HTTP 1.1 
> w/IPv6 (as you said), and for HTTP 1.0 and IPv6 there could 
> be a small win or a 
> small loss. For HTTP1.0/IPv4, there seems to be most likely 
> to be a loss in 
> efficiency.
> And (correct me if I'm wrong, HTTP is not one of my areas of 
> expertise), most 
> web servers today run HTTP 1.0 and IPv4, so to me it seems 
> like this gives us a 
> loss in the "normal case". Therefore, I'm still not convinced 
> on the technical 
> part.

I would also not claim as an expert on HTTP implementation :) I would say that HTTP 1.1 and IPv4 are more popular. It still shows gains with your equations, and all cases show gain with the availability of 2 bits from either spare or wise use.  

> On the other hand, I agree that this seems simple enough, so 
> it does not hurt 
> complexity-wise to add it if you get a consensus on the 
> technical side.
> 

> Zhigang> Lastly, note that our proposal is not only aimed at 
> TCP HC. It can be
> Zhigang> used as a general way to share context between 
> packet flows within a
> Zhigang> subnet.
> 
> This can be added to the format of the IR-CR for other 
> profiles even if it is 
> not in the TCP profile. The format of the IR-CR packet is 
> specified on a 
> profile-basis and even if we don't add it to TCP-IR-CR, 
> there's nothing to say 
> it cannot be used for other profiles, therefore I don't think 
> this is an 
> argument for adding it to the TCP profile.
> 
> 
> Regarding "suffix match" in the draft: Do you expect this to 
> occur often? I 
> cannot see this being something that can be used often and 
> you might as well 
> have a reserved pattern that could mean for example "50% 
> prefix match", so you 
> improve on the figures I presented above, by removing 
> "matched-len" for this 
> pattern.
>

This is a good suggestion. I will think more about it.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 10 Dec 2003 10:49:48 +0100

Kristofer, Zhigang, and others,

I think Kristofer makes some very important points here...

> Zhigang:
> You make a number of valid points. I still believe that the 
> largest part of the 
> flows can be replicated by exact match, thus making n>1 for 
> the common case.

Yes, for the scenarios I can see where there would be any
inter-flow correlation between IP-addresses, most cases
should be with an exact match (see below).

> Regaring n=50 being unreasonable, I did a quick test.
> Using the "trafshow" (http://soft.risp.ru/trafshow/index_en.shtml)
> program that shows open connections in realtime, I opended
> my web browser (Opera 7.21) to one of Sweden's most popular web
> sites, www.aftonbladet.se. What I got was something 
> like 70 connections within a few seconds, even though I 
> filtered to show only that specific host.

I think this is an example of the cases we have been aiming
at when developing context replication for the TCP profile.

> Yousuf>I would also suggest to evaluate the cost and gain for 
> the TCP port #s and use bits with maximum gain. Since, we
> are still discussing rohc-tcp draft. TCP port  #s are also
> using 2*n bits more for indicating port # compression. If we
> use the same formula for the TCP port #s, which has 2
> bits for src and dest port discriminator. The  8 bit source
> and 8 bit destination port matches results into the following 
> formula, with the same analysis as yours
> 
> Hmm.. I'm not sure my analysis really works on TCP ports. 
> Here, we are likely to see the ephemeral port be prefix
> matched almost all the time, since the normal allocation
> scheme will be more or less sequential. Even if I open 50 
> "near-simultaneous" connections, I won't be getting any exact 
> matches on the port numbers. Due to this behavior, TCP
> ports "partial matching" makes more sense to me than addresses.

This is another important key-point. I have been convinced that
it might happen rather often that many flows passing through
the same compressor/decompressor have the same source and/or
destination IP address. The case Kristofer exemplified above
is the typical example, and this would realistically happen
over a "compressed link", as compression is usually applied
on access links, where at least one IP address will be the
same for most connections. Having compression for port numbers
also makes sense as ports are usually sequentially assigned
and will thus "be close" to each other for all these parallel
connections. 

Although I can see cases when also IP addresses will "be close",
I do not think these cases are as obvious and common. Further,
for the cases I can see, I do not think compression is as
important, as these will not at all be comparable (in #'s) to
the example with HTTP multiple connections (as exemplified above). 

/L-E

---

From: [email-masked]
Date: Wed, 10 Dec 2003 13:07:04 -0500

Hi Kristofer,

As you said, n = 70 could be an extreme case. There are also the cases
where n=1 or close to 1. One simple example: HTTP 1.1 origin server, 
regardless the content of the web sites.

I also tested www.aftonbladet.se using IE as browser and Ethereal as 
packet sniffer. I saw one TCP connection. And I expected this. That 
is because we have a HTTP proxy server for the subnet in my office. 

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.

(Back to your test result, I guess it could be caused by the following
reasons. You should know better than me.
- you don't have an HTTP 1.1 proxy server
- your browser does not supports 1.1
- the origin server at www.aftonbladet.se does not support HTTP 1.1)

Note that theses are not fine points of HTTP. (I'm risking repeating
myself since unfortunately I don't see your reply on those points.)
They are important considering what is the real purpose/usefulness of TCP
context replication, or the entire TCP HC profile.

If we want to reduce "bit-over-the-air" and the associated delay, which
is the goal of TCP HC, persistent connection in HTTP 1.1 is probably
the first thing we should do (if it hasn't been done). This has been
well studied in many papers/experiments. So, n=1 or n close to 1 will
be common cases, if it hasn't been so. Do you agree?

RE encoding, that's something we can refine later after we agree IP
address compression is part of TCP profile. As a matter of fact, I don't
even see IPv6 format in current TCP draft. We're already one step ahead
and need to have the overall picture to proceed.

BR,
Zhigang

> Sent: December 10, 2003 02:03 AM
> Hi Zhigang & Yousuf,
> You make a number of valid points. I still belive that the 
> largest part of the 
> Using the "trafshow" 
> (http://soft.risp.ru/trafshow/index_en.shtml) program that 
> shows open connections in realtime, I opended my web browser 
> (Opera 7.21) to one 
> of Sweden's most popular web sites, www.aftonbladet.se. What 
> I got was something 
> filtered to show only 
> that specific host. Maybe not the best example (it could be 
> an extreme case), 
> but it shows that it definitely is not unrealistic for a very 
> much used web page.
> But maybe there's no point in discussing the finer points of 
> HTTP, we can 
> proably both make examples showing things one way or the 
> other. Since it is just 
> the three of us discussing this right now, I'd like to see 
> what the others think 
> before we continue this.
> 
> If it is to be added, I'd prefer if you had a more simple 
> encoding (as you 
> mention that you have prepared) that could only match a few 
> of the most useful 
> cases. I dislike this "variable number of bits" encoding. If 
> you could have an 
> enconding that always is a multiple of octets, then I'd be 
> much more happy. 
> We've tried to have as much byte-alignment as possible in the 
> TCP packet 
> formats, so it would help if this also was that.
> 
> the TCP port #s
> Yousuf>and use bits with maximum gain. Since, we are still 
> discussing rohc-tcp
> Yousuf>draft. TCP port  #s are also using 2*n bits more for 
> indicating port #
> Yousuf>compression. If we use the same formula for the TCP 
> port #s, which has 2
> Yousuf>bits for src and dest port discriminator. The  8 bit 
> source and 8 bit
> Yousuf>destination port matches results into the following 
> formula, with the
> Yousuf>same analysis as yours
> 
> Here, we are likely to 
> see the ephemeral port be prefix matched almost all the time, 
> since the normal 
> allocation scheme will be more or less sequential. Even if I open 50 
> matches on the 
> port numbers. Due to this behavior, TCP ports "partial 
> matching" makes more 
> sense to me than addresses.
> 
> BR,
> [email-masked] wrote:
> > Hi Kristofer,
> > 
> > 
> >>account  the "matched-len" field from your draft as well? 
> > 
> > 
> > You're right. I didn't mention it for two reasons:
> > - the matched-len is very small compared to the prefix anyway.
> > - the size of matched-len depends on encoding. If it is
> > a concern, matched-len can be encoded more efficiently with
> > less bits, e.g. use 1 bit to encode the most common case, etc.
> > (basically, the similar idea you mentioned below for the 
> suffix-match.)
> > 
> > 
> >>Also, you will have a 2*n-bit 
> >>gain/flow ratio  should be (n is the number of multiple TCP 
> connections 
> >>as in your mail):
> >>
> > It seems you assumed only one of the address fields can be 
> compressed?
> > I'm not sure that's always true. But I won't spend time on 
> it now. For
> > the sake of argument, let's assume above n*2 term is correct.
> > 
> > 
> >>source address (full match on dest), we get:
> >>
> > Two points: 
> > - X (i.e. prefix match) could be much larger than 64 bits
> > - matched_len_width can be less (see above). Using your
> > own assumption of x=64, matched_len_width can be just 1 bit.
> > 
> > But this is just some fine points compared to my next comment.
> > 
> > 
> > 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.
> > 
> > 
> >>And for a 16-bit IPv4:
> >>
> > Same points as for IPv6: X can be larger (e.g. 24 bits) and 
> > matched_len_width can be smaller (e.g. 1 bits). So it would
> > be (24 - 1 - 2*n) = (23 - 2*n) / n.
> > 
> > See above for comments on n.
> > 
> > 
> >>gain for HTTP 1.1 w/IPv6 (as you said), and for HTTP 1.0 and 
> >>IPv6 there could be a small win or a  small loss. 
> >>For HTTP1.0/IPv4, there seems to be most likely to be a loss in 
> >>efficiency.
> > 
> > 
> > I have to disagree. See above.
> > 
> > 
> >>expertise), most web servers today run HTTP 1.0 and IPv4, so 
> >>to me it seems like this gives us a  loss in the "normal case". 
> >>Therefore, I'm still not convinced on the technical part.
> > 
> > 
> > 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.
> > 
> > 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.
> > 
> > 
> >>it does not hurt complexity-wise to add it if you get a 
> >>consensus on the technical side.
> > 
> > 
> > Good.
> > 
> > 
> > Agree, that alone is not an argument for adding it to TCP profile. 
> > 
> > 
> >>occur often? I cannot see this being something that can be 
> used often and 
> >>you might as well have a reserved pattern that could mean 
> for example "50% 
> >>prefix match", so you improve on the figures I presented 
> above, by removing 
> >>"matched-len" for this pattern.
> > 
> > 
> > I honestly don't know how often "suffix match" will occur, but think
> > it's something useful to plan in protocol. 
> > 
> > And yes, there are more efficient encoding like you 
> mentioned above. 
> > We do have some detailed ideas but didn't include the them in our 
> > first draft (though it is too early). It's good that you bring up 
> > this issues.
> > 
> > BR,
> > Zhigang
> 
>

---

From: [email-masked]
Date: Wed, 10 Dec 2003 17:12:42 -0600

Hi Kristofer & Lars-Erik,
Please find my answers in this email. My comments don't have any indentation of ">". 

Also, I have asked this before but I didn't get any answer. Could anyone please tell me why discriminator in replicate_format_0 on Page 32 of rohc-tcp-05 has 4 bits and only one value.

   replicate_format_0  ::=  discriminator,                     %  4 bits

> Sent: Wednesday, December 10, 2003 2:03 AM

Please consider the following byte-aligned structure.

For IPv4:
 
Option 1: Encoding will be in bytes. 2 bits for matched-len in bytes. Three un-matched bytes is not sent for destination. I am considering that detination is full match most of the time. matched-len for both src and dest can be placed together. There will still be byte alignment problem with the matched-len fields.

ip_src_addr.matched_len			% 0 (No Match & Full Match) or 2 bits
ip_dest_addr.matched_len		% 0 (No Match & Full Match)or 2 bits
ip_src_addr,                        % 0 (Full Match); unmatched 8, 16 or 24 bits; 32 bits (No Match)
ip_dst_addr,                        % 0 (Full Match); unmatched 8 or 16 bits ; 32 bits (No Match)

Option 2: 2 bits for matched-len in bytes. unmatched bits would be 6, 14, or 22 bits. There won't be any byte alignment problem with the matched-len.

ip_src_addr.matched_len			% 0 (No Match & Full Match) or 2 bits
ip_src_addr,                        % 0 (Full Match); unmatched 6, 12, or 22 bits ; 32 bits (No Match)
ip_dest_addr.matched_len		% 0 (No Match & Full Match)or 2 bits
ip_dst_addr,                        % 0 (Full Match); unmatched 6, 12, or 22 bits ; 32 bits (No Match)

I think option 2 is better, but I would let the WG decide.

For IPv6: 
4 bits for matched-len in bytes. unmatched bytes will be 1 to 15. matched-len for both src & dest can be placed together and this creates a byte alignment.

ip_src_addr.matched_len			% 0 (No Match & Full Match) or 4 bits
ip_dest_addr.matched_len		% 0 (No Match & Full Match)or 4 bits
ip_src_addr,                        % 0 (Full Match); unmatched 8, 16, 24 ... 120 bits; 128 bits (No Match)
ip_dst_addr,                        % 0 (Full Match); unmatched 8, 16, 24, ... 112 bits ; 128 bits (No Match)

> the example with HTTP multiple connections (as exemplified above). 

The HTTP multiple connection example is already commented by Zhigang that why it is not that frequent. I have said in my last posts that limiting context replication to 1 host and 1 server is an unnecessary limitation. We are totally ignoring another dimension of multiple hosts over a "compressed link". I have given these cases before few times. Please see the following post: 
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01853.html

Could you please tell me why these cases are not obvious and common. I see them occuring more than multiple TCP connections between 1 host and 1 server. The reason is the common use of HTTP 1.1, and also proxy, would not let multiple TCP connections to occur.

I have given this number before. I am repeating it here again. If we have m multiple hosts in the system with compressible IP addresses, then the saving is m*(gain per flow). The saving will be 55*m bits for HTTP 1.1./IPv6. 

Thanks,
Yousuf

---

From: Fredrik Lindström (LU/EAB)<[email-masked]>
Date: Thu, 11 Dec 2003 08:15:13 +0100

Hi Yousuf

I think these discriminator bits exist just for padding at the moment, I don't know if the intension is to increase the number of replicate formats.

I have some more comments on the format (section 6.5.5.1 in the TCP draft) see arrows (<--) below.
Its just minor errors and I think the packet formats will be updated soon.

replicate_format_0  ::=  
	discriminator,                     %  4 bits
      format,                            %  1 bit <-- What is this format bit for?
      ip_id.discriminator,               %  1 bit
      ip_src_addr.discriminator,         %  1 bit
      ip_dst_addr.discriminator,         %  1 bit
      ip_tos.discriminator,              %  1 bit <-- No field for sending TOS below
      ip_ttl.discriminator,              %  1 bit <-- No field for sending TTL below
      tcp_src_port.discriminator,        %  2 bits
      tcp_dst_port.discriminator,        %  2 bits
      tcp_ack_number.discriminator,      %  1 bit
      tcp_ecn_and_reserved.discriminator,%  1 bit
      order_flag,                        %  1 bit
      presence_flag,                     %  1 bit
      ip_dont_frag,                      %  1 bit
      tcp_flags_urg,                     %  1 bit
      tcp_flags_ack,                     %  1 bit
      tcp_flags_psh,                     %  1 bit
      tcp_flags_rsf,                     %  2 bits
      header_crc,                        %  8 bits <-- Which crc is this and what is it                  
                                                       caculated over?
      msn,                               % 16 bits
      tcp_seq_number,                    % 32 bits
      ip_src_addr,                 %  0 or 32 bits
      ip_dst_addr,                 %  0 or 32 bits
      ip_id,                       %  0 or 16 bits
      tcp_src_port,             %  0, 8 or 16 bits
      tcp_dst_port,             %  0, 8 or 16 bits
      tcp_ack_number,              %  0 or 32 bits
      tcp_ecn_and_reserved,        %  0 or 8 bits
								     <-- We should have format for TOS,TTL 
                                                         and also for tcp_window but observe
									   that also a discriminator for                                      
	                                                   window is missing.
      tcp_options,         %  variable no. of bits

/Fredrik Lindström

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: den 11 december 2003 00:13
To: [email-masked]; [email-masked]
Cc: Lars-Erik Jonsson (LU/EAB); [email-masked]; [email-masked]
Subject: RE: [rohc] IP Address Compression for Context Replication

For IPv4:

For IPv6: 

Thanks,
Yousuf

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 11 Dec 2003 10:20:45 +0100

Yousuf,

> I have given this number before. I am repeating it here again.
> If we have m multiple hosts in the system with compressible IP
> addresses, then the saving is m*(gain per flow). The saving
> will be 55*m bits for HTTP 1.1./IPv6. 

Consider the most common scenario for HC, i.e. compression over
the last link to a single end host. There you usually only have
ONE single host on the link, which means one address is always
the same (replicable), while other addresses are totally random
(only replicable when we have multiple connections to the same
peer host).

/L-E

---

From: [email-masked]
Date: Thu, 11 Dec 2003 09:25:48 -0600

Hi Fredrik,
Thanks for the answer. 

If the discriminator is only for padding, then we should utilize it for compression. Instead of sending null 4 bits, why not use it for the 2 additional bits of the src/dst discriminator. This will increase compression efficiency without causing any cost (analysis from Kristofer - http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01877.html). 

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 tell compressor/decompressor which format to use. If someone sees it, then I will appreciate a response. If not then we should take the discriminator out and change its name to pad.

You are right we are missing some other fields. Can the authors of draft-ietf-rohc-tcp-05.txt comment on the other fields also?

Regards,
Yousuf

> From: ext Fredrik Lindström (LU/EAB)
> [mailto:[email-masked]]
> Sent: Thursday, December 11, 2003 1:15 AM
> To: Saifullah Yousuf (NRC/Dallas); [email-masked]; Liu
> Zhigang.C (NRC/Dallas)
> Cc: [email-masked]
> I think these discriminator bits exist just for padding at 
> the moment, I don't know if the intension is to increase the 
> number of replicate formats.
> 
> Also, I have asked this before but I didn't get any answer. 
> Could anyone please tell me why discriminator in 
> replicate_format_0 on Page 32 of rohc-tcp-05 has 4 bits and 
> only one value.
> 
> Option 1: Encoding will be in bytes. 2 bits for matched-len 
> in bytes. Three un-matched bytes is not sent for destination. 
> I am considering that detination is full match most of the 
> time. matched-len for both src and dest can be placed 
> together. There will still be byte alignment problem with the 
> matched-len fields.
> 
> ip_src_addr,                        % 0 (Full Match); 
> unmatched 8, 16 or 24 bits; 32 bits (No Match)
> ip_dst_addr,                        % 0 (Full Match); 
> unmatched 8 or 16 bits ; 32 bits (No Match)
> 
> 
> Option 2: 2 bits for matched-len in bytes. unmatched bits 
> would be 6, 14, or 22 bits. There won't be any byte alignment 
> problem with the matched-len.
> 
> ip_src_addr,                        % 0 (Full Match); 
> unmatched 6, 12, or 22 bits ; 32 bits (No Match)
> ip_dst_addr,                        % 0 (Full Match); 
> unmatched 6, 12, or 22 bits ; 32 bits (No Match)
> 
> 4 bits for matched-len in bytes. unmatched bytes will be 1 to 
> 15. matched-len for both src & dest can be placed together 
> and this creates a byte alignment.
> 
> ip_src_addr,                        % 0 (Full Match); 
> unmatched 8, 16, 24 ... 120 bits; 128 bits (No Match)
> ip_dst_addr,                        % 0 (Full Match); 
> unmatched 8, 16, 24, ... 112 bits ; 128 bits (No Match)
> 
>  
> 
> 
> 
> The HTTP multiple connection example is already commented by 
> Zhigang that why it is not that frequent. I have said in my 
> last posts that limiting context replication to 1 host and 1 
> server is an unnecessary limitation. We are totally ignoring 
> another dimension of multiple hosts over a "compressed link". 
> I have given these cases before few times. Please see the 
> following post: 

Thanks,
Yousuf

---

From: [email-masked]
Date: Thu, 11 Dec 2003 18:39:30 -0600

Hi Lars-Erik,
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.

Regards,
Yousuf

> Sent: Thursday, December 11, 2003 3:21 AM
> Cc: [email-masked]; [email-masked]

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 12 Dec 2003 10:05:29 +0100

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 12 december 2003 01:40
> To: Lars-Erik Jonsson (LU/EAB); [email-masked];
> [email-masked]
> 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.
> 
> Regards,
> Yousuf
>

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 12 Dec 2003 10:10:49 +0100

> 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

---

From: Fredrik Lindström (LU/EAB)<[email-masked]>
Date: Fri, 12 Dec 2003 10:43:45 +0100

Yousuf

"If the discriminator is only for padding, then we should utilize it for compression. Instead of sending null 4 bits, why not use it for the 2 additional bits of the src/dst discriminator. This will increase compression efficiency without causing any cost (analysis from Kristofer - http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01877.html)."

Yes it is possible to use these bits, but I am quite sure that the replicate packet is about to change so if it is possible after the update I don't know. But on the other hand that's not the big problem as I see it, the problem is to convince the working group that it is worth adding your IP src, dest compression and then the IPR is a big issue. Personally I am not convinced that it is worth it, of course there are occasions where it is good, but how often do they occur and how much will it save. I think that it is more likely that for example two flows will have the same source address but random destination address but I have not thought that much about it yet. 

"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 tell compressor/decompressor which format to use. If someone sees it, then I will appreciate a response. If not then we should take the discriminator out and change its name to pad."  

What I meant was to have multiple packet formats for context replication as with the normal CO-packets.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: den 11 december 2003 16:26
To: Fredrik Lindström (LU/EAB); [email-masked];
[email-masked]
Cc: [email-masked]

Hi Fredrik,
Thanks for the answer. 

Regards,
Yousuf

Thanks,
Yousuf

---

From: Fredrik Lindström (LU/EAB)<[email-masked]>
Date: Wed, 17 Dec 2003 10:31:50 +0100

I agree with Ghyslain and Kristofer. I don't think IP/AC is important enough to include in 
Context Replication. And as Kristofer said it is just "conditionally non-assertive".

/Fredrik Lindström

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Kristofer Sandlund
Sent: den 17 december 2003 09:00
To: [email-masked]
Subject: Re: [rohc] IP Address Compression for Context Replication

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,

[email-masked] wrote:
> 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
> 
> 
>>From: ext Ghyslain Pelletier [mailto:[email-masked]]
>>Sent: Tuesday, December 16, 2003 9:30 AM
>>To: Saifullah Yousuf (NRC/Dallas); [email-masked]
>>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, Kristof

er'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
>>
> 
>

---

From: "West, Mark" <[email-masked]>
Date: Wed, 17 Dec 2003 10:09:17 -0000

Hi Yousuf,

I think that the 'cost' of adding an additional replicate format is
non-negligible...

The reason why there is a single replicate packet is because you want to
allow pretty much all combinations of changes.  Having multiple replicate
packets means that you have to (ahem) replicate much of the base packet
format.  This makes more text in the draft (ok, maybe not a big deal) and
has to be accommodated in implementations.  Kristofer may like to comment on
that..!  But it's more complexity and more to document / implement and more
to go wrong!

My view is that the IR-Replicate format for TCP is already complicated
enough (in fact, I'd much rather make it simpler than add more to it...)

IR-Replicate is an optimisation to improve the compression of short-lived
flows.  If we accept this, then keeping the complexity of replication low is
a desirable goal since there are many scenarios where it won't actually
achieve anything.

Insofar as the conditional non-assertion applies to this standard (i.e. the
patent is only asserted against those who claim IPR on *this* standard), I
don't have a problem with that.  However, IANAL...

At the moment, we've got enough work on our plates trying to knock *all* the
packet formats into shape, without getting mired in an argument about
replication.  Constructive help on straightening everything else out would
be much more useful, to me at least...

Thanks,

Mark.

> Sent: 17 December 2003 00:35
> To: [email-masked]; [email-masked]
> 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
> 
> 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.
> 
> 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. 
> 
> 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.
> 
> 
> 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. 
> 
> 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 
> /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 
> /msg01884.html)
> 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. 
> 
> 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.
> 
> 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: 
> 
> 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.  
> 
>

---

From: "West, Mark" <[email-masked]>
Date: Wed, 17 Dec 2003 11:43:11 -0000

Hi Kristofer, all,

I specifically addressed the complexity issue in another mail...

... however, let me take this opportunity to say that I agree with Ghyslain's summary of the discussion and with Kristofer's response (and that I share his concerns).

Cheers,

Mark.

> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: 17 December 2003 08:00
> To: [email-masked]
> > 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. 
> > 
> multiple hosts, we will use replicate_format_1. Thus, Kristof
> 
> > the subject 
> draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 18 Dec 2003 12:36:15 +0100

Hi all,

I come to the same conclusion as others on this issue, and I also
agree with Marks opinion that we should rather simplify CR than
making it more complex. CR is itself an optimization, and we
should learn from previous mistakes when it comes to complexity.

/L-E

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of West,
> Mark
> Sent: den 17 december 2003 11:09
> To: [email-masked]'; Ghyslain Pelletier (LU/EAB);
> [email-masked]