Re: Re: [Idr] why has 4096 bytes limit on BGP messages size?

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 14 June 2007 18:27 UTC

Return-path: <idr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu33-0008J4-K0; Thu, 14 Jun 2007 14:27:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu32-0008In-MR for idr@ietf.org; Thu, 14 Jun 2007 14:27:56 -0400
Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyu30-00040P-BW for idr@ietf.org; Thu, 14 Jun 2007 14:27:56 -0400
Received: by wa-out-1112.google.com with SMTP id j5so908008wah for <idr@ietf.org>; Thu, 14 Jun 2007 11:27:53 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gm6dxBea/tClT3XyXW3Yia0kfvqOg53v3mhIBVgsnfBvBP/U+A3qjFbK9L5ajIvWYTVN8CsUCgFA7mt/LX8MTnJ4EleyB6+JLKdcZPDK61NqpB4OXxLhEnNLX7Py5e3wWqWgBa+DjsynFIaxWXljS+RJ28Y8jJClQURIPNTwfog=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m+jXOT6CoBzmraxB9KJf/E2ghef+SwZv0V0TpgSTp8aLG78UBWR4bw+GIvp1ZxtEWNG/yw2NeC2Nrd0XwJSV4+w09t1xiWnSwRDm09y9l1m9gQQtJeuA/MBShskV2lzTWHn8tBmCT7DMYcdG1efHpWIixes37pQyA9BCGbT41tA=
Received: by 10.114.106.1 with SMTP id e1mr2121249wac.1181845673287; Thu, 14 Jun 2007 11:27:53 -0700 (PDT)
Received: by 10.114.154.5 with HTTP; Thu, 14 Jun 2007 11:27:53 -0700 (PDT)
Message-ID: <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com>
Date: Thu, 14 Jun 2007 11:27:53 -0700
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Subject: Re: Re: [Idr] why has 4096 bytes limit on BGP messages size?
In-Reply-To: <20070614135339.GA10519@scc.mi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> <20070614135339.GA10519@scc.mi.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: idr <idr@ietf.org>
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Hi Jeff,

I had a few doubts.

> - Messages encoded in some sort of TLV format probably need a full PDU
>   kept in memory at the same time.  This is because a sane
>   implementation will validate the PDU contents against TLV constraints
>   (either implied by the TLV or by the protocol) before doing *anything*
>   to it.
Are you saying keeping/ allocating a PDU bigger than 4k bytes is a problem?

> - Having a fixed sized buffer means you can allocate it *once* and be
>   done with it.
If I remember correctly what glibc does, it does not make a brk system
call everytime, it itself keeps a pool of memory, and does not give it
back to the OS. I think allocating a few buffers of different sizes
for such a design would help.

> - You're going to have one of these buffers for each of your peering
>   sessions.  You don't want it to be large.
Its again a memory management issue of an implementation right. We
could allocate a central pool and extract memory from there.

Thanks,
Vishwas

On 6/14/07, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Thu, Jun 14, 2007 at 06:58:06PM +0800, Fenggen Jia wrote:
> > Then why not other limit,how is 4096 bytes derived, thanks.
>
> It wouldn't shock me if it had to do with the MTU of a FDDI link but
> that's complete speculation.
>
> Aside from the 4k limit, here's some things to keep in mind when writing
> protocols.  Mostly IMO:
> - Messages encoded in some sort of TLV format probably need a full PDU
>   kept in memory at the same time.  This is because a sane
>   implementation will validate the PDU contents against TLV constraints
>   (either implied by the TLV or by the protocol) before doing *anything*
>   to it.
> - Having a fixed sized buffer means you can allocate it *once* and be
>   done with it.
> - You're going to have one of these buffers for each of your peering
>   sessions.  You don't want it to be large.
> - You want the PDU to be "big enough" to be able to transport your
>   information usefully.  If you're regularly exceeding a 4K message in
>   BGP, you're probably not passing around Internet reachability.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr