Dear DCCP'ers.
Gerrit has been working on improving the CCID-3 implementation in Linux,
and this has raised the question of whether we can now progress the
'sender sends RTT estimate' option that was originally specified (and
recommended) in RFC 5348 and which was submitted
asdraft-renker-dcc
I support the concept of this whole heartedly and agree it would give benefit.
--
twitter imcdnzl
web http://www.next-genit.co.uk
On 18 August 2010 12:42, Gorry Fairhurst wrote:
>
> Dear DCCP'ers.
>
> Gerrit has been working on improving the CCID-3 implementation in Linux, and
> this has raise
Hi guys,
You might be interested in our implementation of a sender-based TFRC
version described here :
http://manu.lochin.net/publications/jourjon_icc07.pdf
a longer version is also available here :
http://manu.lochin.net/publications/jourjon09sender.pdf
Regards
Manu
--
"This email and any at
Hi Gorry & Gerrit,
Nice to see that there is new work proposed on TFRC and DCCP. I will
read it soon, and hope others do the same and send comments on the list.
As an operational point: for a while now the DCCP working group has
been in a slow progress of winding down, so it is a good quest
Hi Pasi,
I want to know whether DCCP is in the process of being abandoned.
If it is, the DCCP WG would save many people (not only Gorry and me)
time by declaring the protocols as abandoned, ideally by changing the
status of the documents
If however there is still IETF support for this protocol,
Hi Gerrit,
On Aug 19, 2010, at 6:50 AM, ger...@erg.abdn.ac.uk wrote:
I want to know whether DCCP is in the process of being abandoned.
I don't understand the question. DCCP protocol is specified in a
series of standards track RFCs, so it is out there for anyone to use.
If there are errors
Just to add an indication of interest:
Provided that we get MulTFRC published as an Experimental RFC, we'd
like to pursue further DCCP work: a MulTFRC CCID, maybe a small-packet
variant, ...
Cheers,
Michael
On Aug 18, 2010, at 8:10 PM, Pasi Sarolahti wrote:
Hi Gorry & Gerrit,
Nice to s
Pasi,
thank you for your reply and for pointing out the responsibility of the IETF.
This has clarified the situation much.
Actually the question of "who is going do deal with this" is very important,
since I don't think that this single draft will be the only thing, as there are
other problems, s
Hi,
On 2010-8-20, at 8:26, Gerrit Renker wrote:
> thank you for your reply and for pointing out the responsibility of the IETF.
> This has clarified the situation much.
>
> Actually the question of "who is going do deal with this" is very important,
> since I don't think that this single draft wi
| 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
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
Hi all,
I hesitate to write something that sounds like a commercial for my own
stuff, but it really just fits so well:
Lars wrote:
Also note that when I say "maintenance", I mean we should be doing
bug fixes and minor improvements that make the currently specified
DCCP protocol more app
Ok, so a couple of questions:
Gerrit, Gorry: if there is support to take this forward, how close to
ready would you think we are -- are there open issues? Would it be
realistic to think about WGLC in about few months of time? With quick
reading I couldn't identify any contentious issues in
Lars, -
| > 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 a
> Later, Gerrit wrote:
>
> > It is a chicken-and-egg problem. In its current form, the TFRC
> implementation buys no compelling performance advantage over using UDP.
>
> (let's ignore the word "performance" here, I think it doesn't quite fit -
> but it's about the compelling advantage, i.e. reas
On Aug 23, 2010, at 7:28 AM, Gerrit Renker wrote:
Later, Gerrit wrote:
It is a chicken-and-egg problem. In its current form, the TFRC
implementation buys no compelling performance advantage over using
UDP.
(let's ignore the word "performance" here, I think it doesn't quite
fit -
but it
what the applications that would need TFRC today? everything seems
handled by TCP or UDP...
On Mon, Aug 23, 2010 at 7:28 AM, Gerrit Renker wrote:
>> Later, Gerrit wrote:
>>
>> > It is a chicken-and-egg problem. In its current form, the TFRC
>> implementation buys no compelling performance advanta
On 23 August 2010 15:00, Saverio Mascolo wrote:
> what the applications that would need TFRC today? everything seems
> handled by TCP or UDP...
and everything seems handled by Microsoft ... so why looking at new
transport protocols ;)
> On Mon, Aug 23, 2010 at 7:28 AM, Gerrit Renker wrote:
>>>
On 23 August 2010 19:01, Emmanuel Lochin wrote:
>
> On 23 August 2010 15:00, Saverio Mascolo wrote:
> > what the applications that would need TFRC today? everything seems
> > handled by TCP or UDP...
>
> and everything seems handled by Microsoft ... so why looking at new
> transport protocols ;)
On 20 Aug 2010, at 19:54, Pasi Sarolahti wrote:
Ok, so a couple of questions:
...
Group: would you support this to become a DCCP working group item
for a proposed standard RFC? I will assume that people who respond
"Yes" are committing to participate in reviewing this and the
subsequent ve
Based on the feedback, there seems to be pretty good support for doing
this draft as a DCCP working group item, and this seems a straight-
forward improvement to TFRC. Therefore, authors, please submit the
next version as a DCCP working group draft, with the draft name set
accordingly. The r
Hi,
and with my AD hat on, I would like to see this document progress MUCH faster
than the UDP-encaps document did. If possible, WGLC before Beijing.
Lars
On 2010-9-8, at 17:24, Pasi Sarolahti wrote:
> Based on the feedback, there seems to be pretty good support for doing
> this draft as a DC
Hi all,
I'm glad to see this as a DCCP draft. Although some of the descriptions of
problems are surprising, they are not that contentious; and the option itself
seems, simply, useful.
Some comments on the draft itself.
* I might prefer to reorder Section 3 and Section 2. Lead with the opti
Hi,
Here are a few comments, no hats on. Generally, I think the draft reads well
and is easy to understand, and I didn't find any major issues with it.
* I like it how section 2 describes the problems clearly and in good detail.
After reading the section, there isn't much question why this opti
I'll try to respond to this on behalf of the authors, here is what I think:
* This seems a straight-forward piece of work that could be implemented
quickly too. It has been raised before, but I think now would be an
excellent time to progress this. It needs to be PS and should take one
IETF-c
On Aug 23, 2010, at 1:38 AM, Gorry Fairhurst wrote:
I'll try to respond to this on behalf of the authors, here is what I
think:
* This seems a straight-forward piece of work that could be
implemented quickly too. It has been raised before, but I think now
would be an excellent time to pro
26 matches
Mail list logo
