Re: [Linux-decnet-user] DECnet buffer size
Brought to you by:
chrissie_c,
ph3-der-loewe
|
From: Steven W. <st...@gw...> - 2003-05-27 22:49:41
|
Hi, > > I'm going to leave well enough alone. We only use the small 576-byte buffer size for DECnet traffic. I don't want IP > traffic using such small packets, so I don't want to set the MTU for the device to be that small. Until I see a problem > with dropped DECnet packets, I'm going to assume DECnet packet disassembly/reassembly is working fine. > Ok :-) > When you say there is a negotiation of sizes in the "connection" start up, what do you mean? In DECnet, there's lines, > circuits, and logical links. Logical links are what processes set up and tear down, and I assume that's where DECnet > messages are segmented and handed down as packets to the circuit layer, and then to the line (physical) layer (except > Ethernet bundles the line layer and the circuit layer into one). In IP, I thought the MTU applied to the physical > layer, and segmentation in an IP network occurs lower in the protocol stack. Does linux-decnet negotiate buffer sizes > each time a logical link is established, or when the circuit comes up? If the latter, I assume it is negotiating buffer > sizes as part of router discovery. > > Larry Baker > US Geological Survey > There are two variables which apply to DECnet packet sizes. Block size is a link layer concept based upon (for broadcast circuits) the smallest block size advertised in a hello message on that link. We don't actually take too much notice of that because most messages we send are either smaller than the minimum guarenteed size or they are dealt with by the other mechanism. The block size which is advertised in hello messages from Linux boxes is based on knowledge of what kind of device is in use for Linux 2.4 and for Linux 2.5 its based on the device mtu (which makes more sense to me). The other mechanism is a per-logical link negotiation in which a size is offered by the connecting end of the link and also by the accepting end of the link and then the smaller of the two sizes is used by both ends. In Linux 2.5 the offered size is based upon the block size of the device or the ADVMSS paramater which can be specified by iproute2 (note this dosn't affect ip as well). Fragmentation in DECnet is very very basic. Unfortunately, due to the fact that whole packets only are acknowleged, if you send a packet thats too large there is very little that you can do. You can't cut it down and send only part of it because when the acknowledgement comes back you won't know if its for the original large packet (which eventually made it though some network path or other) or whether its the new smaller packet thats being acknowledged. Its a pity, but at the moment, I don't see any way around that. In fact since there is no equivalent of an ICMP frag needed, you can only guess that the reason a packet can't get to a destination is due to an mtu problem (well unless you are tunneling over IP and the tunnel MTU drops for example, but then you can use IP fragmentation to get around it). Steve. |