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 cs.waikato.ac.nz> 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"
<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/
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
|