| The first question is whether the IETF should spend cycles on maintaining
| DCCP. At the moment, I believe the answer is yes, although I will note that
| actual deployments will at some point in the future become important in order
| to argue that the IETF should continue to spent the cycles. But, as I said, at
| the moment I think the answer is yes.
Ok, we have agreement.
| 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. 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.
| 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.
|
| > 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.
If in addition the traffic also has to be encapsulated, the advantage over UDP
congestion control in userspace comes in as another question.
I wrote this to Gorry after seeing the same problems with the RTT sampling over and
over again and suggested to pick up the sender-RTT estimation again.
There are other problems in using TFRC, the present problem is that the receiver
often gets the estimated RTT wrong.
Gerrit
