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

From: [email-masked]
Date: Thu, 4 Dec 2003 09:51:44 -0600

Hi Lars-Erik,

Thank you for your reply. 

> This is not true, and answers so far have been rather
> skeptical to the idea, both because of the IPR and for
> technical reasons.
> 
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. 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. 

> Probably not. RAND-terms is usually not considered sufficient
> if an "IPR-free" solution is required.
> 
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

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 05 Dec 2003 08:57:38 +0100

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,
	Kristofer Sandlund, Effnet AB