Hi,

If I remember correctly, the 484 byte limit of SNMP was the amount available within 
the UDP message. So your numbers may be slightly high still. Did you calculate in the 
overhead of the transport layer headers? If you plan to allow different transport 
mappings you should probably calculate the limit for each mapping.

dbh

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards
> Sent: Tuesday, May 04, 2004 2:39 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: syslog transport fragmentation
>
> I think this is reasonable, so I agree. Probably -protocol
> should  recommend that the message is below 500 bytes - an
> efficiency hint...
>
> Rainer
> PS: I am out of office during most of this month with limited
> connectivity.
>
> ----- Ursprüngliche Nachricht -----
>    >Von: "Anton Okmianski"<[EMAIL PROTECTED]>
>    >Gesendet: 03.05.04 21:37:23
>    >An: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>
>    >Betreff: syslog transport fragmentation
>    >
>    >Hi!
>    >
>    >I am pondering what recommendations/requirements we should set for
>    >maximum datagram sizes in syslog UDP transport protocol.
> Messages of
>    >certain size would have to be fragmented.  I have done
> some research
>    >and want to propose that we set the following strict limits on
>    >datagram sizes:
>    >
>    > - IPv4 - fragment to max datagram size of 512 bytes
>    > - IPv6 - fragment to max datagram size of 1196 bytes
>    >
>    >This means that the maximum size of non-fragmented syslog message
>    >would be about:
>    >
>    > - IPv4 - 499 bytes
>    > - IPv6 - 1183 bytes
>    >
>    >Now, the justification.  At first, I was going to propose that the
>    >limit for non-fragmented message would be just the max IP datagram
>    >size of 65,536 bytes and then suggest the above only as a
>    >recommendation.  However, it is quite clear from reading the
>    >literature that many UDP/IP implementations out there do
> not support
>    >large packet sizes even though they are allowed by specifications.
>    >This means that we will be risking low interoperability
> if we leave it
>    >up to implementors or administrators to figure out when
> fragmentation
>    >should kick in.  The disadvantage of specifying low size limits is
>    >that fragmentation (and its huge overhead) kicks in faster.
>    >
>    >Many successful UDP protocols limit IPv4 datagrams to
> somewhere in the
>    >range of 512 bytes: TFTP, DNS, BOOTP, SNMP, RIP...  So,
> if we go with
>    >that size, we will be safe. I presume they do it for the
> same reasons
>    >of interoperability and avoiding IP fragmentation.  The
> 512 byte limit
>    >for IPv4 datagrams let you stay under the 576 minimum MTU for IPv4
>    >with all the IP headers. I derived a similar number for
> IPv6 (1196),
>    >but taking its minimum MTU of 1280 and subtracting the
> same amount of
>    >padding for IP header + 20 bytes for the extra size of
> IPv6 header.
>    >This is the methodology suggested by IPv6 spec (rfc2460 sec 8.3).
>    >
>    >I think that most syslog messages should be smaller than 499 bytes
>    >and, therefore, it would good compromise between performance and
>    >interoperability consideration to specify the above datagrams size
>    >limits. Let me know if you agree or disagree.
>    >
>    >Thanks,
>    >Anton.
>    >
>    >
>
>
>
>


Reply via email to