Iljitsch, See below:
> -----Original Message----- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Friday, August 03, 2007 2:57 PM > To: Templin, Fred L > Cc: Joe Touch; Joe Macker; Fred Baker; Gorry Fairhurst; > Stephen Casner; Internet Area > Subject: Re: Mucking with IP ID > > [CCing int area again] > > On 3-aug-2007, at 2:13, Templin, Fred L wrote: > > >> I don't think "unless RFC4821" is reasonable either; > perhaps "unless > >> they make measures to react to silent failure, by RFC4821, or > >> some other > >> means, e.g., application timeout and retry with other MTUs". > > > I like the spirit of your text, but the problem I have with > > it is that it doesn't say how the application can discern loss > > due to an MTU restriction from loss due to, e.g., congestion. > > I strongly disagree here. PMTUD isn't something that should > happen in applications. It's easy to get it wrong, and > applications tend to stick around for a LONG time. I believe all Joe was saying was that an application that can discern MTU-related loss (with or without explicit indications from the network), and has a way to reduce the size of the messages it sends, should probably do so. > Applications that use UDP or other transports that can't implement > RFC 4821 should clear the DF bit in IPv4 so that fragmentation can > happen as needed. Anything else will cause breakage. Any application can clear DF in the packets it sends and hope that the final destination has a large enough buffer to reassemble any fragmentation that occurs in the network. But, it would be well advised to try to ascertain the reassembly buffer size first - unless it has some way of knowing or guessing this in advance. > > For *-in-IPv4 tunnels, the choke point will come in routers in > > the middle of the network that have to support decapsulating > > tunnel endpoints. They may need to support reassembly for *many* > > such tunnels, and so they need to place a conservative and > > convenient upper bound on MRU - say, 2KB. > > I think I get why we've been disagreeing on MRU issues: it > seems what > you mean when you say "MRU" is "maximum size of packets that can be > reassembled". The MRU is generally dictated by hardware limitations > and as such not all that interesting. But the maximum packet size > that a tunnel endpoint is willing to reassemble is a very important > choice. Limiting this to 1500 bytes or some such will probably come > back to haunt us as jumboframe capability becomes more common. (Note > that the tunnel egress device may not support jumboframes for other > interfaces, but if the tunnel ingress point does, it's likely that > large packets will come in as fragments.) By: "MRU", I mean the same thing as for "EMTU_R" (Effective MTU to Receive) per ([RFC1122], Section 3.3.2). > >> The IEEE isn't the only arbiter of link specs, but if you're > >> picking an > >> IEEE spec, you need to pick 1500, which means you probably want > >> something like 1200 for the reasons you cite (reasonable levels of > >> recursion). > > > 1200 is too small for IPv6-in-(foo)-in-IPv4 tunnels; IPv6 > > will refuse to run over any link that can't do at least 1280. > > 1200 or 1280 is way too conservative. Trying to reserve room for > IPsec tunnels is a no-win game IMO, and IPsec users don't care about > performance anyway. For anything else ~ 1450 as a "shouldn't be > subject to too much fragmentation" packet size used by UDP apps > should be workable. For *-in-IPv4 tunnels, if we have EMTU_R >= 2KB and Maximum Tunnel Fragment Size (MTFS) = 1500B, then the tunnel MTU can be as large as the largest IPv4 packet (the only limitation being the 16bit IPv4 length field). > >> Because it's not a BCP; it's an update to a standards-track > >> doc, not an > >> operational recommendation (which is what I think of BCPs > as being). > >> Perhaps 2003bis should encompass 6-in-6, etc. as well. > > > The 2KB MRU is an operational recommendation, so maybe that > > should go as a 1pg BCP? In terms of the tunnel encapsulation > > requirements, why couldn't we just write up a brief spec and > > say: "This document updates RFC2003 (et al)"? (Then again, > > maybe we could get by with just tucking the 2KB MRU into > > the spec also...) > > Note that EDNS0 often advertises a 4096 byte packet size. If we > aren't going to allow a full 9000 byte "standard" jumboframe or > larger, I'd shoot for around 4.5 kilobytes. If you're going to > fragment anyway you may as well get to send packets of at least a > somewhat decent size, 2048 is hardly enough to bother with. The 2048 isn't an MTU; it is only the minimum MRU (or, EMTU_R) for reassembling tunneled packet fragments, which could in turn be reassembled into a quite large packet at the final destination (assuming the final destination configures an EMTU_R >> 2KB). > BTW, on FreeBSD and MacOS X: > > > sysctl -a | grep dgram > net.local.dgram.maxdgram: 2048 > net.local.dgram.recvspace: 4096 > net.inet.udp.maxdgram: 9216 > net.inet.raw.maxdgram: 8192 Good to know, but I don't think that relates to this discussion? Thanks - Fred [EMAIL PROTECTED] _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
