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
On 11/5/06, Bob Briscoe [EMAIL PROTECTED] wrote:
DCCP folks,
I've posted Flow Rate Fairness: Dismantling a Religion
draft-briscoe-tsvarea-fair-00.pdf to internet drafts. It
explains my strong concerns about the way fairness is thought about in the
Internet Community. I show a proper basis
Another possible variant for CCID 2, in addition to allowing
slowly-responding AIMD
parameters, would be to specify a variant of CCID 2 for small-packet
flows.
This would be a little more more work than the slowly-responding AIMD
option, but
wouldn't be so bad to specify or implement, and would
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:
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.
- Sally
http://www.icir.org/floyd/
DCCP.notes
Description: Binary data
Mmm, but isn't the 576 byte 'have to support fragmentation' limit a more
practical minimum to work to?
Richard
Gorry Fairhurst wrote:
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
