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

[Brian E Carpenter <[e-mail]>]

On 11/06/2013 08:59, Warren Kumari wrote:
> On Jun 10, 2013, at 4:12 PM, Brian E Carpenter <[e-mail]> 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: 

Sure, except that this would add it to a standards track draft
(fwiw).

    Brian

>>> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> 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
> 
> 
> 
>