Subject: [Softwires] Header overheads - 4V6T vs 4V6E

From: Rémi Després <[email-masked]>
Date: Mon, 25 Jul 2011 11:59:28 +0200

Wojciech,
 
IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too much in favor of translation (4v6T) vs encapsulation (4V6E). 

The draft has:   
   +------------------------+--------------------+---------------------+
   | Item                   | 4V6 Translation    | 4V6 Mapped Tunnel   |
   |                        | mode               | Mode                |
   +------------------------+-------- ... -------+---------------------+
   | Overhead in relation   | a) 0% b) 0%        | a) 4.36% b) 1.71%   |
   | to average payload of  |                    |                     |
   | a) ~550 bytes b) 1400  |                    |                     |
   | bytes).                |                    |                     |
   | ------------------     | ------------------ | ------------------  |

An IPv4 packet having a 550 B payload is 570 B long (ignoring possible IPv4 options):
- 4V6T adds 20 B (3.5 %).
- 4V6E adds 40 B, (7.0 %).  
An IPv4 packet having a 1400 B payload is 1420 B long (at least)
- Translation adds 20/1420 = 1,4 %
- Encapsulation adds 40/1420 = 2,8 %

This gives:
   | ------------------     | ------------------ | ------------------  |
   | Overhead in relation   | a) 3.5% b) 1.4%    | a) 7% b) 2.8%       |
   | to average payload of  |                    |                     |
   | a) ~550 bytes b) 1400  |                    |                     |
   | bytes).                |                    |                     |
   | ------------------     | ------------------ | ------------------  |

In addition, a complete comparison should take in consideration the length of layer-2 headers, as well as that of the physical preambles if any. This leads to even less different overhead ratios.

Also, 4V6 devices can be expected to soon have an increasing part of their traffic in IPv6. With this, the 4V6 overhead in % will soon decrease accordingly. 
 
Conclusion: this line of the table deals with a difference that, although it is real, is not significant compared to other considerations (e2e transparency is one that deserves a separate discussion).

Regards,
RD

---

From: Mark Townsley <[email-masked]>
Date: Mon, 25 Jul 2011 06:26:08 -0400

Header overhead percentage is fairly useless alone. A real-world comparison would need take into account the speed of a given connection.

- Mark

On Jul 25, 2011, at 5:59 AM, Rémi Després wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 25 Jul 2011 21:22:54 +0200

When the access medium's capacity is expensive (read radio spectrum),
even single digit percentage points translate to significant expense.
That is independent of the access speed.

-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jul 2011 09:52:24 -0400

Remi,

> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too much in favor of translation (4v6T) vs encapsulation (4V6E).

Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6
transport. It thus seemed fair to measure and compare the overhead as
relative to IPv6 encapsulation, and not IPv4, since there is no way to
send an IPv4-only packet, and the useful data is the Layer4+ payload.
Doing it your way you show mixes the basic IPv6 overhead. In any case,
subtract the left column from the right and one arrives at the figure
at pretty much the figures in the original table.

> In addition, a complete comparison should take in consideration the length of layer-2 headers, as well as that of the physical preambles if any. This leads to even less different overhead ratios.

With the relative consideration, this actually doesn't matter... And
we can choose to ignore the detail of specific radio link protocols
that can segment longer packets into many many more.

-Woj.

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Jul 2011 16:46:54 +0200

Well, I made my point (with one more comment below, at the end).  
Up to WG contributors, and to operators, to appreciate what is really important to them.

Note also that, in 3GPP where power consumption is important, the IPv4v6 bearer option completely avoids the IPv6 header overhead (no need for 4V6).

In wifi, I am still convinced that the impact on power consumption of +6O vs +40 octets per IPv4 packet will remain negligible in real life, especially as IPv6 will become the majority.

The impact of translation on e2e transparency will be discussed in another email.

RD

> that can segment longer packets into many many more.

Different view here.
The _ratio_ of power-consumption increase, if n bytes are added to each packet, does depend on the total length of packets (with their headers of all layers, including link and physiscal).

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jul 2011 16:56:45 +0200

> Note also that, in 3GPP where power consumption is important, the IPv4v6 bearer option completely avoids the IPv6 header overhead (no need for 4V6).

That is totally orthogonal...
> The impact of translation on e2e transparency will be discussed in another email.

I trust that it will explain how to build an e2e transparent system
with a stateful port restricted NAT44 in the path.
If not, the IPv4 e2e transparency of encapped or translated transports
is very much the same.

-Woj.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 26 Jul 2011 15:30:35 -0500

Remi,

> Note also that, in 3GPP where power consumption is important, the IPv4v6
> bearer option completely avoids the IPv6 header overhead (no need for 4V6).

Don't follow this. Could you please expand?

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Rémi Després
> Sent: Tuesday, July 26, 2011 10:47 AM
> To: Wojciech Dec
> Cc: Softwires-wg; Wojciech Dec (wdec)
> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
> 
> Note also that, in 3GPP where power consumption is important, the IPv4v6
> bearer option completely avoids the IPv6 header overhead (no need for 4V6).
> 
> In wifi, I am still convinced that the impact on power consumption of +6O vs
> +40 octets per IPv4 packet will remain negligible in real life, especially as
> IPv6 will become the majority.
> 
> >> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too much
> in favor of translation (4v6T) vs encapsulation (4V6E).
> >>
> >> The draft has:
> >> In addition, a complete comparison should take in consideration the length
> of layer-2 headers, as well as that of the physical preambles if any. This
> leads to even less different overhead ratios.
> >
> The _ratio_ of power-consumption increase, if n bytes are added to each
> packet, does depend on the total length of packets (with their headers of all
> layers, including link and physiscal).
> 
> 
> >
> > -Woj.
> 
>

---

From: Mark Townsley <[email-masked]>
Date: Tue, 26 Jul 2011 16:39:09 -0400

> Don't follow this. Could you please expand?

I read that statement as in "cellular mobile" networks, dual-stack will be deployed predominately with native dual-stack rather than 4V6 solutions. I do think that the jury is likely still out on that.

In any case, anyone who lived through the dial-up years with all the different header negotiation options we had then and happily left behind will likely roll their eyes at this "my header is shorter than yours!" discussion. Header size is the tail wagging the dog in a solution, and outside of the low-power/sensor world well within the point of diminishing returns as an advantage of one approach vs. another.

- Mark

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 26 Jul 2011 15:58:21 -0500

Mark,

You raise a good point. Header compression could be useful, however, that comes at a cost. 

Are you suggesting 'header compression' on the radio interface, or between the UE and the GGSN/P-GW?

Cheers,
Rajiv

> From: Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 4:39 PM
> To: Rajiv Asati (rajiva)
> Cc: Rémi Després; Wojciech Dec; Softwires-wg; Wojciech Dec (wdec)
> I read that statement as in "cellular mobile" networks, dual-stack will be
> deployed predominately with native dual-stack rather than 4V6 solutions. I do
> think that the jury is likely still out on that.
> 
> In any case, anyone who lived through the dial-up years with all the different
> header negotiation options we had then and happily left behind will likely
> roll their eyes at this "my header is shorter than yours!" discussion. Header
> size is the tail wagging the dog in a solution, and outside of the low-
> power/sensor world well within the point of diminishing returns as an
> advantage of one approach vs. another.
> 
> - Mark
> 
> >
> > Cheers,
> > Rajiv
> >
> >
> >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring possible
> IPv4
> >> options):

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jul 2011 23:02:02 +0200

On 26 July 2011 22:39, Mark Townsley <[email-masked]> wrote:

> deployed predominately with native dual-stack rather than 4V6 solutions. I
> do think that the jury is likely still out on that.
>
> In any case, anyone who lived through the dial-up years with all the
> different header negotiation options we had then and happily left behind
> will likely roll their eyes at this "my header is shorter than yours!"
> discussion. Header size is the tail wagging the dog in a solution, and
> outside of the low-power/sensor world well within the point of diminishing
> returns as an advantage of one approach vs. another.
>
> - Mark
>
> There is another perspective here: Overhead (of any kind) that consumes a
resource which could be used by other users, or by the user, is a waste, and
thereby cost. This is more applicable to certain environments rather than
others, but it is not something that can be dismissed as not applying.
The overhead can be "optimized" (eg compressed), but that involves making
more system changes and other trade-offs (eg IPinIP compression, which is
anything but common)

-Woj.

> >> The impact of translation on e2e transparency will be discussed in
> another
> >> email.
> >>
> >> RD
> >>

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jul 2011 23:07:46 +0200

On 26 July 2011 23:02, Wojciech Dec <[email-masked]> wrote:

> Typo...
> others, but it is not something that can not be dismissed as not applying.
>> >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring
>> possible IPv4
>> >> options):

---

From: Hui Deng <[email-masked]>
Date: Tue, 26 Jul 2011 17:20:59 -0400

Hi Mark,

Most today 3GPP discussion yesterday is about UE mobile case, other than UE
as the CPE case, I believe this work should be taken sooner or later.

Regards,

-Hui

2011/7/26 Mark Townsley <[email-masked]>

---

From: Mark Townsley <[email-masked]>
Date: Tue, 26 Jul 2011 23:40:13 -0400

> Are you suggesting 'header compression' on the radio interface, or between the UE and the GGSN/P-GW?

It's a general statement. 

For example, in the dial-up days virtually every layer had some way to reduce encapsulation size. PPP could compress away HDLC-like framing, protocol ID, etc. We had VJ TCP Header Compression and even payload compression as well. L2TP published an L2TP Header Compression document to show that it could have a header-size smaller than PPTP. And of course ROHC. As link-speeds increased, these progressively fell by the wayside in terms of wide support and usage. There are good reasons for that.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Jul 2011 09:17:19 +0200

Rajiv,

As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, 3GPP has introduced the IPv4v6 bearer.
With it, mobile nodes exchange packets natively in bot IPv4 and IPv6.
This saves 20 octets per IPv4 packet compared to a translation that replaces an IPv4 header by an IPv6 header.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Jul 2011 09:34:27 +0200

Le 26 juil. 2011 à 23:07, Wojciech Dec a écrit :
•••

> 
> There is another perspective here: Overhead (of any kind) that consumes a resource which could be used by other users, or by the user, is a waste, and thereby cost. This is more applicable to certain environments rather than others, but it is not something that can not be dismissed as not applying.

Right.
However, if by accepting a small overhead, one significantly simplifies service specification, implementation validation, training, operation, maintenance, this cost can be largely compensated by other costs that are saved.
For a transition solution, this can be even more so.

The perspective has to be global. 

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Jul 2011 10:58:09 +0200

Le 26 juil. 2011 à 16:56, Wojciech Dec a écrit :
...

> with a stateful port restricted NAT44 in the path.

OK, there may be ambiguity about e2e.
Here, I meant _network_ e2e transparency, i.e. from customer site to customer site.

1.
With network e2e transparency:
- There is no assumption to be made about NAT44 behaviors in CE's.
(We all know that there are many different NAT and FW behaviors, so that any assumption may prove to be wrong with a few existing NAT devices.)
- Except for the port-set restriction of shared IPv4 addresses, complete backward compatibility of the IPv4 service is ensured.

2.
If some CE's are given full IPv4 addresses, they may use protocols for which NAT44 isn't needed.
With network e2e transparency, no restriction on IP options they may use is needed.

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jul 2011 16:02:51 +0200

On 27 July 2011 09:17, Rémi Després <[email-masked]> wrote:

> This saves 20 octets per IPv4 packet compared to a translation that
> replaces an IPv4 header by an IPv6 header.
>

Sure, but it's fair to say that in the context of a (any) 4V6 solution (they
run on IPv6, not IPv4), the native v4 leg/bearer/capability/pdp type isn't
used or needed. As such this aspect looks  orthogonal to the 4v6 overhead
discussion...

Regards,
Wojciech.

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Jul 2011 17:47:30 +0200

Le 27 juil. 2011 à 16:02, Wojciech Dec a écrit :

> Sure, but it's fair to say that in the context of a (any) 4V6 solution (they run on IPv6, not IPv4), the native v4 leg/bearer/capability/pdp type isn't used or needed. As such this aspect looks  orthogonal to the 4v6 overhead discussion...

The question that remains is "why does one need a translation" if:
- There already exists a solution for native IPv6 AND IPv4 (the IPv4v6 bearer)
- This solution consumes less energy than both translation and encapsulation.

Note that, for stateless address sharing, the 4rd address mapping can be directly combined with the IPv4v6 bearer.

Cheers,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jul 2011 21:00:37 +0200

Remi,

On 27 July 2011 17:47, Rémi Després <[email-masked]> wrote:

> Sure, but it's fair to say that in the context of a (any) 4V6 solution
> (they run on IPv6, not IPv4), the native v4 leg/bearer/capability/pdp type
> isn't used or needed. As such this aspect looks  orthogonal to the 4v6
> overhead discussion...
>
>

Sure, the IPv4v6 bearer is for *plain* IPv4 and IPv6 traffic - it's
plain/regular dual stack. By definition, the 4V6 translated or encapsulated
solutions would use only the v6 dimension (the v4 dimension not being
useful), along with their respective overheads (or lack thereof).

>
> Note that, for stateless address sharing, the 4rd address mapping can be
> directly combined with the IPv4v6 bearer.
>

Yes, and that applies to *any* 4V6 variant.

Regards,
-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jul 2011 21:04:50 +0200

Also note that the same applies to any dual stack access set-up (eg DSL with
PPP).

On 27 July 2011 21:00, Wojciech Dec <[email-masked]> wrote:

>>> >>>> |                        | mode               | Mode
>>>  |
>>> >>>> | bytes).                |                    |
>>> |
>>> >>>> | bytes).                |                    |
>>> |