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

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

> Why wouldn't we add a sentence in -oversized-header-chain
> following this:
> 
>> 6.  Updating RFC 2460
>> 
>>   If an IPv6 packet is fragmented, the first fragment of that IPv6
>>   packet (i.e., the fragment having a Fragment Offset of 0) MUST
>>   contain the entire IPv6 header chain.
> 
> 
> The entire IPv6 header including the header chain SHOULD NOT exceed
> 256 octets.
> 
> (or whatever magic number we decide on).
> 
> We might need some words to justify that, but they can be found
> in this thread.

You mean like what I said in the below email: 
>> 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.

Fine idea!

W

> 
> Regards
>   Brian Carpenter
> 
> On 11/06/2013 03:03, Warren Kumari wrote:
>> 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
>> 
>> 
>> .
>> 
> 

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
to try to do it with ten blunt axes instead.
    --  E.W Dijkstra, 1930-2002