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

Tony Li <tli@cisco.com> Mon, 18 June 2007 03:35 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 1I0816-0004ZO-Ry; Sun, 17 Jun 2007 23:35:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0814-0004Xy-OS for idr@ietf.org; Sun, 17 Jun 2007 23:34:58 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0814-0005c3-Do for idr@ietf.org; Sun, 17 Jun 2007 23:34:58 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Jun 2007 20:34:58 -0700
X-IronPort-AV: i="4.16,432,1175497200"; d="scan'208"; a="166956763:sNHT49700160"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5I3YvEV004300; Sun, 17 Jun 2007 20:34:57 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5I3YvtV019658; Mon, 18 Jun 2007 03:34:57 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 20:34:57 -0700
Received: from [192.168.0.100] ([10.21.65.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 20:34:57 -0700
In-Reply-To: <20070618010911.EB17F1140496@mail.zjgsu.edu.cn>
References: <20070618010911.EB17F1140496@mail.zjgsu.edu.cn>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <982B9BFB-D286-40D5-9A07-3D2DB51BC102@cisco.com>
Content-Transfer-Encoding: 7bit
From: Tony Li <tli@cisco.com>
Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size?
Date: Sun, 17 Jun 2007 20:34:56 -0700
To: "Fenggen Jia" <fgjia@mail.zjgsu.edu.cn>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 18 Jun 2007 03:34:57.0392 (UTC) FILETIME=[A487D700:01C7B159]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2300; t=1182137697; x=1183001697; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20<tli@cisco.com> |Subject:=20Re=3A=20[Idr]=20why=20has=204096=20bytes=20limit=20on=20BGP=2 0messages=20size? |Sender:=20; bh=Vqso/18hs56fDtfB7trY55rtoC3lzC0zHjpaSm4ja28=; b=yUMIJA3Lf3Dh9RrnmJg50IjEo15otUM363Ewu2Wz4jAkkS4l/1sHNVJ0mvczMKzJmGkKcynK e13wy79WGuRPQJ+CZwmNDq8bwZAhg4rCu8Za/9gk+6Jnwa1kBHy63WxD;
Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
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

On Jun 17, 2007, at 6:12 PM, Fenggen Jia wrote:

> 	I think my inital question is why the protocol has 4K limit on  
> messages sizes,that is different from the implementation,an  
> implementation may chose to use large read or write buffer(>4K) to  
> handle multiple updates one time,still my question is if message  
> size limit is a good pratice in protocol design?


Hmmm, ok, I guess we haven't been explicit enough.  I'll try again:

1) First, an implementation should NOT be using a message size that  
is different than the specified 4k message size limit.  If an  
implementation sends messages more than 4k, then other  
implementations will not be able to parse them.  If an implementation  
cannot receive 4k messages, then it will also not be able to  
interoperate.

1a) Having a fixed size is good because it makes the protocol  
implementations easy.  There is no point to having complexity in an  
implementation if it provides no benefit.  Large messages don't  
provide a wonderful benefit, as they need to be large enough to carry  
the path attributes and associated prefixes.  For this purpose 4k is  
probably adequate to date.

1b) Historically, 4k was considered a bit wasteful.  Of course, it  
was wonderfully simple compared to EGP which used fragmented  
packets.  Care to parse a 16k jumbo-gram?  Care to debug that?  Trust  
me, it's not fun.

2) The 4k message size is *completely independent* of the TCP window  
size.  An implementation is perfectly free to compose any number of  
messages, each of which is within the 4k limit.  The implementation  
can then cram any number of messages into its TCP socket, up to the  
buffering limits of that TCP.

2a) Thus, the message size is *NOT* performance limiting, except when  
an implementation could actually overfill a message.  Folks  
maintaining current implementations might chime in here as to whether  
or not they see this.

So, in summary, yes, a 4k message size limit is a fine situation *for  
BGP*, for the way that it behaves and the job that it does.  This  
does *NOT* necessarily generalize to other protocols, (e.g. OSPF)  
where 4k exceeds the most common MTUs.  In those cases, you'd end up  
with fragmentation, and that's bad.

Regards,
Tony

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