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

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

>>
>>
>>     
>
>
>
>
>