All IPv4 end hosts are required to accept and reassemble IP packets of size 576 bytes [RFC791]. That doesn't mean IPv4 links have to support this value. In slow networks, the largest possible packet may take a considerable amount of time to send [RFC3819]. A smaller MTU may be desirable, e.g. 100's of bytes. If this were your first-hop link, then TCP would choose an MSS that was smaller than 536 B [RFC 879]. [RFC1144] quotes cases of very low link speeds were the MSS may be 10's of bytes (and notes this is an extreme case). [RFC 3819] also notes that if a new subnetwork technology cannot directly support a "reasonable" MTU with native framing mechanisms, it should internally fragment. That is, it should transparently break IP packets into internal data elements and reassemble them at the other end of the subnetwork. That's the standard position for IPv6. So while it seems OK to say that a 536 B MSS is a baseline for IPv4, some text should explain that a small MSS would be problematic. Gorry On 6/11/06 19:35, "Richard Nelson" <richardn@xxxxxxxxxxxxxxxx> wrote: > Mmm, but isn't the 576 byte 'have to support fragmentation' limit a more > practical minimum to work to? > > Richard > > Gorry Fairhurst wrote: >> Quite so - this is a requirement for IPv6, so choosing 6lowpan as a >> technology example was not the best choice, but the min. MTU in IPv4 *IS* >> tiny. >> >> Gorry >> >> >> On 6/11/06 18:05, "Richard Nelson" <richardn@xxxxxxxxxxxxxxxx> wrote: >> >> >>> The draft you reference includes the text: >>> >>> This is >>> obviously far below the minimum IPv6 packet size of 1280 octets, >>> and in keeping with section 5 of the IPv6 specification >>> [RFC2460], a fragmentation and reassembly adaptation layer must >>> be provided at the layer below IP. >>> >>> I think this shows that people with really small packet sizes recognize that >>> it is largely their problem. >>> So I think a simple warning as Sally proposed would suffice. >>> >>> Richard. >>> >>> Gorry Fairhurst wrote: >>> >>>> Sally, >>>> >>>> I think the argument you put at the end of your email would be fine to >>>> address my concerns on different MSS. >>>> >>>> That leaves the issue of very small MTUs that was again raised at the >>>> meeting today. >>>> >>>> Clearly we can have small MTUs << 576 B. >>>> >>>> An example of a very small MTU is: draft-ietf-6lowpan-problem-05.txt >>>> >>>> >>>> So... What do we say for the case of small MTUs? >>>> >>>> * If you were to use TCP over links with a very small MTU, then PMTUD would >>>> reveal a trivial MSS, and if IPv4 fragmentation were to be used, then we'd >>>> end up with huge runs of fragments per segment, which isn't desirable, and >>>> not "fair" to other traffic. >>>> >>>> * So for TFRC-SP and a small MTU, a default "s" could be an order of >>>> magnitude too large. >>>> >>>> * Can you use PMTUD information to set a valid "s"? >>>> Perhaps - but TFRC-SP is not trying to send large datagrams - so even if >>>> you >>>> enable PMTUD, you'll never learn "s", and that's assuming that PMTUD works >>>> - although if a TFRC-SP endhost happens to share an endpoint with a flow >>>> that uses, say TCP, and discovers the PMTU as an effect of the shared state >>>> of the other flows, then you can learn "s" and be fair to TCP (at least >>>> those that use PMTUD). >>>> >>>> * Things can get very odd if TFRC-SP uses a smaller packet than the PMTU. A >>>> side-question is therefore whether it is wise to allow TFRC-SP with IPv4 >>>> router fragmentation (where this could lead to packet rate >> DCCP/UDP >>>> segment rate), or should it be mandated that for IPv4, this always uses DF? >>>> >>>> Not sure where this leaves the recommendation on small packets. Thoughts? >>>> >>>> Gorry >>>> >>>> On 6/11/06 11:05, "Sally Floyd" <sallyfloyd@xxxxxxx> wrote: >>>> >>>> >>>> >>>>> Gorry - >>>>> >>>>> >>>>> >>>>>>>> * What happens if there is a sudden step-change in the packet size, >>>>>>>> does >>>>>>>> this have any implications. >>>>>>>> >>>>>>>> >>>>>>> Section 6 discusses the use of TFRC-SP with applications that modify >>>>>>> their >>>>>>> packet size in response to changes in the loss event rate, and says >>>>>>> that the >>>>>>> interactions between applications and the transport protocol in this >>>>>>> case will >>>>>>> have to be addressed in documents that are more application-specific. >>>>>>> For applications that vary their packet size for other reasons, RFC >>>>>>> 4342 >>>>>>> says the following: >>>>>>> CCID 3 implementations MAY check for applications that appear to be >>>>>>> manipulating the packet size inappropriately. For example, an >>>>>>> application might send small packets for a while, building up a >>>>>>> fast >>>>>>> rate, then switch to large packets to take advantage of the fast >>>>>>> rate. (Preliminary simulations indicate that applications may not >>>>>>> be >>>>>>> able to increase their overall transfer rates this way, so it is >>>>>>> not >>>>>>> clear that this manipulation will occur in practice [V03].) >>>>>>> We haven't yet explored this for TFRC-SP. I would guess that the >>>>>>> restriction on the sending rate of at most one packet every 10 ms, >>>>>>> combined with the allowed sending rate explicitly in Bytes per second, >>>>>>> and the app's inability to know the packet-dropping or packet-marking >>>>>>> dynamics at the congested routers, would not leave the app with all >>>>>>> that >>>>>>> much room for gaming the transport protocol by varying the packet >>>>>>> size. >>>>>>> But, as I say, I haven't done any analysis or simulations. >>>>>>> >>>>>>> >>>>>> This seems like a reasonable position to me (it would be good note >>>>>> something in the draft). >>>>>> >>>>>> >>>>> Will do. >>>>> >>>>> >>>>> >>>>>>>> * Please clarify text on the impact of a reduced TCP MSS (for >>>>>>>> example a >>>>>>>> reduced MSS that could result from more widespread use of Path MTU >>>>>>>> Discovery >>>>>>>> over Paths with links that do not support an Ethernet-sized MTU). >>>>>>>> The IPv6 >>>>>>>> Minimum MTU could mitigate this. >>>>>>>> >>>>>>>> >>>>>>> I am sorry, but I didn't understand this. You are talking about the >>>>>>> impact >>>>>>> of TFRC-SP in environments where the TCP MSS would be less than 1460 >>>>>>> bytes? >>>>>>> >>>>>>> >>>>>> As I understand it, the design goal for TFRC-SP is to achieve the same >>>>>> bandwidth in bps (as a TCP flow using packets of up to 1500 bytes. >>>>>> This is under the assumption that the TCP MSS is 1460 bytes [Section >>>>>> 4.5]. >>>>>> >>>>>> So my question is what happens to the fairness with TCP, if the TCP >>>>>> MSS is (much) less than 1460 bytes (some PPP links have a much smaller >>>>>> MTU, that would force TCP to use a much smaller MSS) Would TFRC-SP be >>>>>> fair? - I don't think so. >>>>>> >>>>>> One of the use cases for TFRC-SP may be to offer CC on such >>>>>> capacity-constrained links, does the draft comment on this somewhere, >>>>>> and is this an issue that will need to be addressed before deployment? >>>>>> >>>>>> >>>>> I could add more to the draft. Currently it says this: >>>>> >>>>> Instead of using a nominal segment size of 1460 bytes, an >>>>> alternate possibility would have been for TFRC-SP to determine >>>>> the actual Maximum Segment Size (MSS) of the path, and to use >>>>> this for the nominal segment size. While most paths have an MSS >>>>> of 1460 bytes, some paths have a slightly smaller MSS due to >>>>> tunnels, IPv6, and the like, and some other paths have a >>>>> significantly smaller MSS of only 536 bytes. Due to the >>>>> complications of estimating the MSS of the path, and to the fact >>>>> that most paths support an MSS of at least 536 bytes, we have >>>>> decided to use a nominal segment size of 1460 bytes for TFRC-SP. >>>>> >>>>> If the path has an MTU of 500 bytes, and TFRC-SP assumed a TCP MSS of >>>>> 1460 bytes, >>>>> then the TFRC-SP flow would get three times the bandwidth of a >>>>> competing TCP flow. >>>>> And if the path actually had a MTU of 4000 bytes, and TFRC-SP assumed a >>>>> TCP MSS of 1460 bytes, then the TCP flow would get more bandwidth. >>>>> Better to have perfect path MTU discovery, >>>>> but "unfairness" with factors of two or three don't bother me much - >>>>> unfairness with factors >>>>> of 10 or 20 bother me more, or of one flow really squeezing out other >>>>> flows. >>>>> >>>>> What kind of MTUs are you talking about? >>>>> >>>>> - Sally >>>>> http://www.icir.org/floyd/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >> >> >> >> > >
