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