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/ >>> >>> >>> >> >> >> >> >> >
