Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On Jun 10, 2013, at 12:31 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> On 10/06/2013 04:49, Tom Taylor wrote:
>> On 09/06/2013 9:42 AM, Fernando Gont wrote:
> 
> ...
>>> I guess having a L4-pointer would have helped quite a lot.
>>> 
>>> Cheers,
>>> 
>> Would it be practical to define a HBH option that has an L4 pointer and
>> assign a fixed order to it?
> 
> http://tools.ietf.org/html/draft-zhang-6man-offset-option-01
> 
> It didn't fly in this WG at the time.

The issue is that, in order to be able to see header X you need to push all the bits up to header X onto the forwarding engine. Having a header that says "The L4 header is at byte 142" simply pushes the L4 out by another 8 bytes, exacerbating the problem.

This issue is:
1: In order to make a decision on header X the forwarding / filtering engine needs to see header X
2: This require pushing at least <number of bytes from start of packet to end of header X> up to the forwarding engine in a  "cell".
3: Bandwidth into the forwarding engine is expensive / limited, and storage on the forwarding engine is expensive (this is not DRAM ;-))
4: As you don't know (until you've looked) how far into the packet header X is, you need to choose some number and ship that many bytes to the forwarding engine.
5: Having a header that points at the L4 info doesn't help -- by the time you can see it you've already sucked the bits onto the engine. 
6: Having additional logic that "prescreens" the packets looking for a pointer header *could* possibly work, but that is much of the forwarding engine logic - see #3.

Choosing the optimum cell size is the tricky bit. If you increase the cell size you vastly increase cost -- if your competitors don't do the same, you've priced yourself out of the market. 

We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major vendors will sign up for.

W

>   Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett