Yes - just to be clear, TFRC was added as an Item on the new Charter that is currently being approved for DCCP. Gorry On 6/7/06 00:45, "Phelan, Tom" <tphelan@xxxxxxxxxxxx> wrote: > Hi Sally, > >> I am assuming that this would best go in dccp instead of tsvwg... > > I think that's what we decided a few meetings ago... > > Tom P. > >> -----Original Message----- >> From: floyd@xxxxxxxx [mailto:floyd@xxxxxxxx] >> Sent: Wednesday, July 05, 2006 6:05 PM >> To: Phelan, Tom >> Cc: dccp@xxxxxxxx; gorry@xxxxxxxxxxxxxx >> Subject: Re: Preliminary agenda for Montreal >> >>> Here's a preliminary agenda for our meeting in Montreal. >>> Additions/changes/comments appreciated. >> >>> 4. Potential New WG Items >>> * DTLS over DCCP, draft-phelan-dccp-dtls-00 (Tom, 10 min) >>> * RTP over DCCP, draft-perkins-dccp-rtp (Colin, 15min) >>> * DCCP Mobility, draft-kohler-dccp-mobility (?, 10 minutes) >> >> I have another potential new WG item that I would like to talk about: >> TCP Friendly Rate Control (TFRC): Protocol Specification, >> draft-floyd-rfc3448bis-00.txt. >> >> Five or ten minutes would be fine. Sorry for not getting this to >> you earlier. >> >> I am assuming that this would best go in dccp instead of tsvwg... >> >> - Sally >> >> From the draft: >> >> Changes from RFC 3448: >> >> * Incorporated changes in the RFC 3448 errata: >> >> - "If the sender does not receive a feedback report for >> four round trip times, it cuts its sending rate in half." >> ("Two" changed to "four", for consistency with the rest >> of the document. Reported by Joerg Widmer). >> >> - "If the nofeedback timer expires when the sender does not >> yet have an RTT sample, and has not yet received any >> feedback from the receiver, or when p == 0,..." >> (Added "or when p == 0,", reported by Wim Heirman). >> >> - In Section 5.5, changed: >> for (i = 1 to n) { DF_i = 1; } >> to: >> for (i = 0 to n) { DF_i = 1; } >> Reported by Michele R. >> >> * Changed RFC 3448 to correspond to the larger initial windows >> specified in RFC 3390. This includes the following: >> >> - Incorporated Section 5.1 from [RFC4342], saying that >> when reducing the sending rate after an idle period, don't >> reduce the sending rate below the initial sending rate. >> >> - Change for a datalimited sender: >> When the sender has been datalimited, the sender doesn't >> let the receive rate limit it to a sending rate less than >> the initial rate. >> >> - Small change to slow-start: >> Changed so that for the first feedback packet received, >> or for the first feedback packet received after an idle >> period, the receive rate is not used to limit the >> sending rate. This is because the receiver might not yet >> have seen an entire window of data. >> >> * Clarified how the average loss interval is calculated when >> the receiver has not yet seen eight loss intervals. >> >> * Discussed more about estimating the average segment size: >> >> - For initializing the loss history after the first loss event, >> either the receiver knows the sender's value for s, or >> the receiver uses the throughput equation for X_pps and does >> not need to know an estimate for s. >> >> - Added a discussion about estimating the average segment size >> s in Section 4.1 on "Measuring the Segment Size". >> >> - Changed "packet size" to "segment size". > >
