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

[Warren Kumari <[e-mail]>]

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

On Jun 10, 2013, at 4:59 PM, Warren Kumari <[e-mail]> 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: 
>>> 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!

... and we are still planning on doing this as well. Never hurts to have the same things repeated....

W

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