Subject: [RAM] EATing into the core bandwidth

From: Elwyn Davies <[email-masked]>
Date: Mon, 02 Apr 2007 13:03:40 +0100

My mind was obviously too into taxes this Monday morning (the end of the 
UK tax year soon)...

Just a reminder when we are adding up the costs and benefits of the 
various approaches, such as LISP, that some of them impose EAT 
(Encapsulation Added Tax).

Calculations based on the distribution of packet sizes in the current 
network indicate that LISP would impose an extra average overhead on 
IPv4 traffic of around 5 to 7% in bits to be carried.  The exact figure 
depends on the distribution you use but is heavily biassed by the large 
number of TCP ACK packets for which EAT is around 45%.  If the same 
distributions are used for IPv6 traffic the overhead rises to 7 to 9% 
assuming a similar sort of LISP header.

Whilst these are not enormous figures, given the organic growth in 
traffic, they are truly overhead that is applicable to all future 
traffic and that gains no extra revenue. This might be a significant 
factor in an increasingly commoditised backbone network.

/Elwyn

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

---

From: David R Oran <[email-masked]>
Date: Tue, 3 Apr 2007 15:00:49 -0400

On Apr 2, 2007, at 8:03 AM, Elwyn Davies wrote:

> My mind was obviously too into taxes this Monday morning (the end  
> of the UK tax year soon)...
>
> Calculations based on the distribution of packet sizes in the  
> current network indicate that LISP would impose an extra average  
> overhead on IPv4 traffic of around 5 to 7% in bits to be carried.   
> The exact figure depends on the distribution you use but is heavily  
> biassed by the large number of TCP ACK packets for which EAT is  
> around 45%.  If the same distributions are used for IPv6 traffic  
> the overhead rises to 7 to 9% assuming a similar sort of LISP header.
>
> traffic and that gains no extra revenue. This might be a  
> significant factor in an increasingly commoditised backbone network.
>
If this is a real concern we can always do IPHC on the inner header.  
Good point to keep in mind though.

---

From: Andrew Lange <[email-masked]>
Date: Tue, 3 Apr 2007 12:12:40 -0700

On Apr 3, 2007, at 12:00 PM, David R Oran wrote:

>> Just a reminder when we are adding up the costs and benefits of  
>> the various approaches, such as LISP, that some of them impose EAT  
>> The exact figure depends on the distribution you use but is  
>> heavily biassed by the large number of TCP ACK packets for which  
>> EAT is around 45%.  If the same distributions are used for IPv6  
>> traffic the overhead rises to 7 to 9% assuming a similar sort of  
>> LISP header.
>>
> If this is a real concern we can always do IPHC on the inner  
> header. Good point to keep in mind though.

I'm assuming this is RFC 2507-style header compression.

Header compression is computationally expensive, and, from my  
understanding, difficult to do at high speeds.  I do not know of any  
10 Gbps header compression hardware.  This would also add not  
insignificant cost.

Andrew

---

From: David R Oran <[email-masked]>
Date: Tue, 3 Apr 2007 16:09:36 -0400

On Apr 3, 2007, at 3:12 PM, Andrew Lange wrote:

>>> the various approaches, such as LISP, that some of them impose  
>>> EAT (Encapsulation Added Tax).
>>>
>>> overhead on IPv4 traffic of around 5 to 7% in bits to be  
>>> carried.  The exact figure depends on the distribution you use  
>>> but is heavily biassed by the large number of TCP ACK packets for  
>>> which EAT is around 45%.  If the same distributions are used for  
>>> IPv6 traffic the overhead rises to 7 to 9% assuming a similar  
>>> sort of LISP header.
>>>
>>> Whilst these are not enormous figures, given the organic growth  
>>> in traffic, they are truly overhead that is applicable to all  
>>> future traffic and that gains no extra revenue. This might be a  
> understanding, difficult to do at high speeds.  I do not know of  
> any 10 Gbps header compression hardware.  This would also add not  
> insignificant cost.
>
It's not that expensive if you don't do the second-order deltas. Note  
too that you'd likely do this at CE/PE boundaries, which for small  
business is likely to be in the DSL-speed range, and for anything  
other than big enterprises, unlikely to exceed 100Mbps.

Since packet expansion is a concern mostly at the edge, the only  
place I'd recommend it is at the edge where the speeds are modest.