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/
