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

[Erblichs <[e-mail]>]

Danny McPherson, eta al,

	Let me take a stab at this, but do your own investigation..

	IMO, one item is due to the use of TCP by BGP. After one
	RTO timeout, most implimentations use a slow-start after
	idle. To preserve TCP's fast transmit and power of two
	mem allocation the stardard link's MTU is 1.5K, times four
	with a reduction to the closest power of two, thus 4K.

	Oh, and the recieve window size is normally 4 x MTU which
	is then capped at 6K for slow-start.

	Mitchell Erblich
	----------------

	

	

Danny McPherson wrote:
> 
> In RFC 1105 the maximum message size was 1024 octets.  I suspect
> because RFC 1163 added the capability to support multiple prefixes
> (i.e., compression/update packing) they bumped the size to 4096. Note
> that RFC 1163's Appendix 2 states the UPDATE format was changed
> to support multiple "path attributes", when I think they actually meant
> multiple "prefixes".
> 
> As for why it was constrained in the first place, RFC 1164 talks to this
> a bit in section 6.3.  In particular, I suspect the size was constrained
> initially because of this:
> 
>     Due to the stream nature of TCP, all the data for received messages
>     does not necessarily arrive at the same time
>     [...]
>     This can make it difficult to process the data as messages,
>     especially on systems such as BSD Unix where it is not possible to
>     determine how much data has been received but not yet processed.
> 
> One might hypothesize that the selection of the original value of 1024
> had something to the 4.2 BSD-derived systems TCP segment size
> common settings of 1024.
> 
> RFC 1267 incorporated some of the RFC 1164 text directly, in section
> 5.2.
> 
> Of course, I'm just a youngster compared to some of the old folk here,
> especially Yakov, so I'll happily defer  ;-)
> 
> -danny
> 
> ---
> RFC 1267
> 
> 5.2  Processing Messages on a Stream Protocol
> 
>     BGP uses TCP as a transport mechanism.  Due to the stream nature of
>     TCP, all the data for received messages does not necessarily arrive
>     at the same time. This can make it difficult to process the data as
>     messages, especially on systems such as BSD Unix where it is not
>     possible to determine how much data has been received but not yet
>     processed.
> 
>     One method that can be used in this situation is to first try to
> read
>     just the message header. For the KEEPALIVE message type, this is a
>     complete message; for other message types, the header should
> first be
>     verified, in particular the total length. If all checks are
>     successful, the specified length, minus the size of the message
>     header is the amount of data left to read. An implementation that
>     would "hang" the routing information process while trying to read
>     from a peer could set up a message buffer (4096 bytes) per peer and
>     fill it with data as available until a complete message has been
>     received.
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr