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

From: "Fenggen Jia" <[email-masked] >
Date: Mon, 18 Jun 2007 09:12:25 +0800

hi,all,
	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?
Yours,Fenggen

>Then why not other limit,how is 4096 bytes derived, thanks.BTW,whether it's a good pratice in protocol devise to limit message sizes?I see in ripV1 that the maximum PDU length is 576bytes its reason is to avoid IP fragmentation,but in ripng the PDU length is determined only by the link MTU,and in snmp i also doesn't see the message size limit. 
>Yours,Fenggen
>>
>>On Jun 13, 2007, at 10:01 PM, Fenggen Jia wrote:
>>
>>> hi,all,
>>>       I am wondering why BGP has 4096 bytes limit on all its  
>>> messages,should we leave it to the implementator to decide,thanks!
>>
>>
>>Well, the problem with that is that a sender could then create an  
>>arbitrarily long message, which could be arbitrarily problematic for  
>>a receiver.
>>
>>Tony
>>
>
>
>
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

= = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

　　　　　　　　Fenggen Jia
　　　　　　　　[email-masked]  
　　　　　　　　　　2007-06-18

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

---

From: Tony Li <[email-masked]>
Date: Sun, 17 Jun 2007 20:34:56 -0700

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 18 Jun 2007 01:04:59 -0400

Hi Tony,

Some further clarification inline, not for you since you know this,
but for anyone that might still be confusing BGP message size and TCP
buffer size (aka TCP window size).

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

We've been clear to the careful reader.  I mentioned that the TCP
window has nothing to do with the BGP message size.

That was a different person confused about this.

> probably adequate to date.

Right.

> packets.  Care to parse a 16k jumbo-gram?  Care to debug that?  Trust  

Actually EGP was worse than that.  EGP required that you put everythin
in one dategram packet which eventually exceeded the IP 64KB limit.
Fortunately only one network was using EGP when that happenned (NASA
still had Proteon routers that ran EGP and not BGP so they had to take
partial routing and use default - they were even worse off when CIDR
came along but finally retired the Proteons).  Then there was the AGS
FDDI interface that couldn't handle 5 consecutive IP packets or
fragments without dropping the 5th one.  Not amusing when EGP packets
required 5 fragments (somewhere beyond 20KB in size).  Those were
interesting times.  Its boring at times now that things mostly work.  :-)

> buffering limits of that TCP.

I think that is the point people are missing.

> maintaining current implementations might chime in here as to whether  

Yes BGP updates are filled and spill into a second update.  No it is
not performance limiting.  But you knew that.

Performance is determined by the TCP buffer size set.  TCP buffer size
in BSD is set with a setsockopt as I had mentioned before.  TCP buffer
size has nothing to do with BGP message size.

BGP message size has little to do with performance unless as I had
mentioned parsing the attributes such as AS Path more than once ever
became an issue.  If anything it is less an issue over time.

> with fragmentation, and that's bad.

OSPF does not use TCP therefore its message size is relevant to
performance and cannot exceed the MTU.

BGP uses TCP therefore its message size is not relevant to performance
except for internal parsing issues and the MTU is irrelevant to the
BGP message size.

> Tony

Curtis

ps - For those new to IDR (and some of the posters on this thread seem
to be) this sort of mini-lecture on how TCP works and how BGP uses it
is somewhat of a rerun.  The topic or something similar comes up on
this mailing list every few years.

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 17 Jun 2007 23:39:00 -0700

Hi Curtis,

> except for internal parsing issues and the MTU is irrelevant to the
I agree with both the statements above. Having recently written some
DTCP/ IP and AKE implementation from scratch (both work over TCP), I
agree with you. The TCP does not differentiate between packet
boundaries from the application. So if 2 packets of size 2500 are sent
from the application it could be similar to the case of having sent 1
packet of 5000 bytes.

Let me know if I am wrong?

Thanks,
Vishwas

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Mon, 18 Jun 2007 12:18:34 +0530

Hi Vishwas,

> Let me know if I am wrong?

Yup, you are right. The application at the other end would never know if
TCP received two packets each of 2500 bytes or a single packet of 5000
bytes. 

Manav