Hi Anton, thanks for this very helpful post.
> > I have to admit I am not 100% sure what the UDP spec says: If > > a UDP packet becomes fragmented (due to MTU), is it > > guaranteed that the packet will be re-assembled by the > > receivers IP stack before it is passed up to the app layer? > > What if a fragment is missing? Will the whole packet be > > discarded by the stack (UDP is best effort, after all...)? > > Postel's UDP RFC768 from 1980 is 3 pages long with references. Ah, the > good old times! :) indeed ;) > It talks about very few things. Besides, > fragmentation is an IP layer issue and not UDP. IP layer must > reassemble the whole packet before providing it to the next layer - be > it UDP or TCP. So, yes, if one fragment is lost, the whole > datagram is > discarded. That's fine with me. If don't receive a partial message and everything is lost, I think this is consistent. If you use UDP, you have accepted packet loss ;) [snip useful info for brevity] > So, I > guess 64Kb limit is problematic for reasons other than > fragmentation. > > But if we impose 1024 byte limit, let's at least make it > something that > is closer to using the whole Ethernet 1500 frame or at least close to > IPv6 minimum MTU, which I think is 1280 bytes. This would still be > consistent with SNMP requirements, which seems to stem from the same > limitation of 1500 byte frame minus IP/UDP header of 28 bytes = 1472. That sounds like a good compromise from my point of view. I'd agree on solving this issue as follows (just a sum-up of your points to show if I have correctly understood): #1 we allow up to 1280 bytes inside the syslog message #2 we recommend to place important data early in the message #3 we warn that a transport mapping may truncate the message after 484 bytes (SNMP lowest limit as of David's post) Every transport mapping is allowed to use #3 at liberty (but should try to avoid it). It is NOT required to ensure that the whole syslog message will be transmitted. This will cause potential interop issues in rare cases, but I think they can be addressed, esepcially if #4 we recommend / demand (?) that an implementation must provide an operator-configurable max message size (configurable between 484 and 1280 bytes) So a proper implementation would look at the operator configured value (default of 1280). So the operator can fine-tune is he has actually one of the rare cases where the size limitation is very low. That all sounds fine to me and I would edit -protcol-03 to include this if nobody objects or has a better solution. I would appreciate if somebody who eventually knows quickly could confirm the 1280 byte IPv6 minimum MTU. Thanks, Rainer
