Quoting Arnaldo Carvalho de Melo:
| On 11/27/06, Gerrit Renker <[EMAIL PROTECTED]> wrote:
| > Quoting Eddie Kohler:
| > | Hi Gerrit, Ian,
| > |
| > | I am not sure I am completely following this discussion, but there is
one
| > | point I wanted to bring up. DCCP senders DO have an estimate of the
| > | round-trip time even BEFORE the first feedback packet, namely from the
| > | Request-Response exchange. RFC 4342 senders and receivers can use the
RTT
| > | measured by the core DCCP protocol. Reading over RFC 4342, this is
extremely
| > | not clear (sorry), but it was our intention. (Sally, this is right,
yes?) We
| > | will put together an erratum for the RFC Editor.
| > This is an experimental feature and also appears in
draft-ietf-dccp-rfc3448bis-00.txt,
| > section 4.2:
| > "If the sender does have a round trip sample when it is ready to
| > first send data (e.g., from the SYN exchange or from a previous
| > connection [RFC2140]), the initial transmit rate X is set to
| > W_init/R, and tld is set to the current time."
| >
| > However, this is a draft, still under revision and subject to further
change.
| >
| > The Linux CCID 3 module is at present not even compliant with 3448 / 4342,
and we are having
| > enough work getting that done. There is therefore at the moment little
point in thinking
| > about what could be done and what should be done: what we are implementing
is RFC 4342/3448,
| > not more.
| >
| > And if what is in the specification was not your intention, then this is
certainly not our problem!
| >
| > You are suggesting and requesting features for which there is no support
currently in the RFCs
| > (see e.g. your earlier suggestion to re-introduce a socket option for
packet sizes).
| >
| > What you are suggesting is helpful only for yourself as a writer of
specifications, but it is not
| > helpful for those who have to implement these specifications. If we give
in to suggestions which
| > are not documented by IETF-reviewed and IETF-approved standards documents,
then we end up doing
| > experimental work while the main target (a standards-compliant DCCP stack)
is not even finished.
| >
| > Therefore, let me put it very clearly: I am against implementing anything
which is not stated in
| > RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk
when the Linux implementation
| > matches these RFCs, but before we have accomplished that: please stop
sending feature requests or
| > annotations which are not part of the publicly and IETF-approved RFCs. For
these purposes, please
| > use [EMAIL PROTECTED] instead.
| >
| > I am sure we can work out a constructive way of dealing with your
interests as well, but it is certainly
| > not via the avenue of implementing feature requests which you state
without contributing in work or in
| > funding.
|
| I violently agree with Gerrit on this one, no one is preventing anyone
| from doing experimental work, the infrastructure is there and if
| changes are required for supporting different ways of the DCCP core
| interacting with any new CCID (experimental or a standard) we'd love
| to hear so as to work on making the Linux DCCP infrastructure as
| useful as possible for the community at large.
|
I can not see your disagreement in this. The fact is that the Linux DCCP
implementation currently is
not compliant with the RFCs and an implementation which only partially
implements a standard is of
not much service to the community. Features which have not met the approval of
public bodies such as
the IETF, on the other hand, serve the interest of only a few and not that of a
larger community.
Therefore, Arnaldo, I fail to see the contradiction in what you are saying with
regard to what I have
stated above.
I also didn't say that doing experimental work is totally impossible - but I do
consider getting the
basics right first.
And lastly: it is only thanks due to your ingenious efforts that the Linux DCCP
implementation has made it
this far, the number of other half-completed implementations
attests to the fact that DCCP,
even without additional feature requests, is hard to implement.
Therefore I do think that
the above arguments are justified, and that experimental features -
whose discussion and
implementation takes time away which could be more fruitfully spent
on finishing the incomplete
DCCP Linux implementation - should come last.
Please let me repeat - I have stated above that I can think of a constructive
way of integrating
Eddies ideas as well, but clearly not in the way of integrating experimental
and feature requests
when the main work is not even finished.
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
