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 protected]>

>
> On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote:
>
> > 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?
>
> 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
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] 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
> >>
> >> 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
> >>
> >> Le 26 juil. 2011 à 15:52, Wojciech Dec a écrit :
> >>
> >>> Remi,
> >>>
> >>> On 25 July 2011 11:59, Rémi Després <[email protected]> wrote:
> >>>>
> >>>> 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).                |                    |                     |
> >>>> | ------------------     | ------------------ | ------------------  |
> >>>
> >>> 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.
> >>
> >> 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).
> >>
> >>
> >>>
> >>> -Woj.
> >>
> >>
> >> _______________________________________________
> >> Softwires mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/softwires
> > _______________________________________________
> > Softwires mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to