Hi, On 2010-8-20, at 14:10, Gerrit Renker wrote: > | The reason I have this opinion is that the energy levels in the WG > | are extremely low, as witnessed by long update cycles for the past few WG > | items and very little in terms of discussion. The community that is > interested > | in DCCP is also not exactly huge, and very few proposals for new work saw > much > | interest during the last few years. > | > These are excuses. As Pasi said, there is a responsibility, and as you say > these > documents are major specs. I don't understand this.
please remember that closing the DCCP WG does NOT mean that the IETF is
abandoning the DCCP protocol or is giving up on its responsibility for
maintaining the DCCP specs.
It merely means that the effort to do so is estimated to be small enough such
that a standalone WG may not be needed. Yes, this is a judgement call.
> The specifications have largely
> been developed through simulation, were published after only little exposure
> to
> Internet testing.
>
> While discussing this last year at netconf 2009, people were asking why an
> IETF
> specification could be published which had seen so little exposure to
> practical
> testing.
>
> There is the TV analogy: thanks to testing, in Europe the PAL standard has
> stood
> the test of time. In America they developed NTSC and had to supply remote
> controls
> to control the colour phase ("Never The Same Colour").
>
> A similar thing happens here: it is normal that a specification based
> largely on
> simulation will behave differently in practice.
>
> Hence there need to be people who can respond to those practical problems,
> and be
> that in form of guidelines how to proceed with 'bug fixes'. It is possible to
> come up with home-grown fixes to problems found in the specification, but
> that is
> comparable to developing home-grown congestion control schemes.
Again: even if we decide to close the WG, that does NOT mean that the IETF
wouldn't be the home for any required maintenance work.
> | We're not abandoning ship. We are shifting gears, however. With the
> | publication of the major specs, DCCP is entering maintenance mode, until
> DCCP
> | deployments necessitate more substantial extensions.
> |
> In that sense I was merely asking who will be looking after these things.
The IETF will, but likely in TSVWG rather than a standalone DCCP WG. (If we
actually close the DCCP WG.)
> | > So please let me know what I can do to best support your work.
> |
> | The absolute best thing anyone interested in DCCP can do is push it out onto
> | the Internet, so it becomes an actively used protocol. This should become
> much
> | easier once the UDP encapsulation spec is done, and implementations are
> | available.
> It is a chicken-and-egg problem. In its current form, the TFRC implementation
> buys
> no compelling performance advantage over using UDP.
Performance will never be the reason for people to chose TFRC or DCCP over UDP
- having congestion control by definition means that there are situations in
which you will loose performance. The reason for choosing TFRC or DCCP will be
the desire for a well-reviewed rate control scheme to avoid having your app
cook up its own home-grown scheme.
> There are other problems in using TFRC, the present problem is that the
> receiver
> often gets the estimated RTT wrong.
Understood. But would it really matter to you whether you took these fixes to
the TSVWG rather than to the DCCP WG?
Lars
smime.p7s
Description: S/MIME cryptographic signature
