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

From: [email-masked]
Date: Fri, 5 Dec 2003 15:59:38 -0500

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

> -----Original Message-----
> 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]
> Subject: Re: [rohc] IP Address Compression for Context Replication
> 
> 
> 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
> 
> [email-masked] wrote:
> > 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
> 
> 
> _______________________________________________
> 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: Kristofer Sandlund <[email-masked]>
Date: Tue, 09 Dec 2003 11:35:25 +0100

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

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

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

Best regards,