Feedback on draft-ietf-dccp-tfrc-voip-05.txt (repost)

Gorry -

> I've done a detailed read through this document, and it
seems that 
> there are
> several NiTs that were not caught during the WGLC, that
 should be 
> fixed.
> Issues that I would like to see considered or addressed
in a new 
> revision
> are below.

Many thanks for the feedback.  Most of the changes that you
suggested
have now been made.  Some specific comments are below.  And
I have
a question below about one of your suggestions.

...
> 3. TFRC-SP
>
> * How could a sender determine an appropriate average
sending size - an
> average implies some history, is this history over the
previous 4 
> periods.

The document now cites RFC3448bis, in a non-normative
fashion, and says
that the average segment size SHOULD be calculated over at
least the 
last
four loss intervals.

> * 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.

> * 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?

...
> 7. Simulation
...
> * I like the first 3 paragraphs of summary, and this
clearly should be 
> in
> the main body of the document.
>
> * IMHO, publishing specific ns2 simulation results in
the body of a
> standards-track RFC is not good practice. There may be
precedents, but 
> the
> approach of using protocol specs to publish data does
not seem good - 
> it can
> also make this data appear as authorative on the topic
(whereas, I'd 
> much
> rather encourage more results by more people). If the
intention is to
> support the case and help illustrate the way this it is
to be used, 
> which is
> what it seems here, then I'd very much prefer the
remainder of 
> section7 to
> appear as an appendix providing the results to support
the arguments.

Yep, done.

Many thanks!

- Sally
http://www.icir.org/floyd/

Sally - response to that last point is inline.

Sally Floyd wrote:
> Gorry -
> 
>> I've done a detailed read through this document,
and it seems that 
>> there are
>> several NiTs that were not caught during the WGLC,
that  should be fixed.
>> Issues that I would like to see considered or
addressed in a new revision
>> are below.
> 
> 
> Many thanks for the feedback.  Most of the changes that
you suggested
> have now been made.  Some specific comments are below. 
And I have
> a question below about one of your suggestions.
> 
> ...
> 
>> 3. TFRC-SP
>>
>> * How could a sender determine an appropriate
average sending size - an
>> average implies some history, is this history over
the previous 4 
>> periods.
> 
> 
> The document now cites RFC3448bis, in a non-normative
fashion, and says
> that the average segment size SHOULD be calculated over
at least the last
> four loss intervals.
> 
OK

>> * 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).

>> * 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?


> ...
> 
>> 7. Simulation
> 
> ...
> 
>> * I like the first 3 paragraphs of summary, and
this clearly should be in
>> the main body of the document.
>>
>> * IMHO, publishing specific ns2 simulation results
in the body of a
>> standards-track RFC is not good practice. There may
be precedents, but 
>> the
>> approach of using protocol specs to publish data
does not seem good - 
>> it can
>> also make this data appear as authorative on the
topic (whereas, I'd much
>> rather encourage more results by more people). If
the intention is to
>> support the case and help illustrate the way this
it is to be used, 
>> which is
>> what it seems here, then I'd very much prefer the
remainder of 
>> section7 to
>> appear as an appendix providing the results to
support the arguments.
> 
> 
> Yep, done.
> 
OK thanks.

> Many thanks!
> 
> - Sally
> http://www.icir.org/floyd/

> 
> 
> 
Gorry

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/

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" <sallyfloydmac.com> 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/

> 
>