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?
LarsAttachment:
smime.p7s
Description: S/MIME cryptographic signature
