Rainer: I was just thinking about the same! :)
I think relay is an extreme case of this situation. Let's look at the client (originator) first. Suppose administrator knows that a particular client is behind a low MTU network. I have actually tentatively (with a big TODO) specified in -transport that clients are RECOMMENDED to have an option where MTU could be specified. This would allow a client to fragment the message on IP level, thus avoiding having to discover MTU or malfunction due to wrong MTU use (truncation by UDP stack). I was thinking, like you, that maybe in this case it is better if client actually sent a multi-part message instead of IP-fragmenting them. I think multi-part messages have an advantage. Normally (without multi-part messages), if one IP fragment gets lost, syslog server will not get the UDP datagram - IP layer will discard it and syslog server may not get any indication that something got lost. If, on the other hand, reassembly is done on a higher level with multi-part messages, then syslog server would at least know that some part was missing and can log a diagnostic message. Sure, this is not a great scheme for detecting lost datagrams, but its better than alternative it seems. I think I like this idea. Allowing relay to partition a message is the next logical step. I think it is more debatable as in this case message is changed in flight, but same general argument holds. You would just have to deal with original multi-part messages being partitioned again by a relay or prohibit this. Nasty, nasty.... It sucks that we have to re-invent IP fragmentation, but we basically have no choice. There will always be messages greater than UDP datagram size. Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Friday, February 13, 2004 12:55 PM > To: [EMAIL PROTECTED] > Subject: -procotol relay operations > > > Hi WG, > > we talked quite a bit about different MTUs for different > transport mapping. We may run into a situation where a > message is larger than is actually supported by the transport > (e.g a hypothetical SNMP trap transport supporting only ~500 > octets). As we have multi-part message in -protocol, a relay > COULD create a multi-part message at this time. This could be > an elegant solution to the minimum size problem, too. You can > directly compare it it IP fragmentation. > > Question now: Is there any objection against specifying it in > that way, at least as a MAY rule for relays. I think it > definitely has advantages > - it allows us to care for the unsual cases... > > Rainer > >
