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

From: [email-masked]
Date: Tue, 9 Dec 2003 12:16:55 -0500

Hi Kristofer,

> Maybe I've misunderstood you, but don't you have to take into 
> 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 
> 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

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.

> 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

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.

> 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

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:
> 
>      (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

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.

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

I have to disagree. See above.

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

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

Good.

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

Agree, that alone is not an argument for adding it to 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.

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

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 10 Dec 2003 09:02:51 +0100

Hi Zhigang & Yousuf,

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

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

Yousuf>I would also suggest to evaluate the cost and gain for 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

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.

BR,
	Kristofer Sandlund, Effnet AB