Hi Tom, Thanks for ur reply..
By my reading of RFC 4342, it seems to be talking about the *initial* sending rate -- that would be before you know what the RTT is.
Yes, that is what is confusing me. Maybe this should be made more clear. Inorder to reiterate what both of us are discussing about: let me put this way: a sender wishing to use CCID 3 starts like this: Case 1 (this is how I understood by reading the RFC): 1)Sends DCCP request (saying its CCID is 3) gets DCCP response, sends DCCP ACK. 2)Sets the sending rate to 1 packet per second, sends packets, gets feedback, gets RTT estimate. 3)Sets the initial sending rate to 2 packets per RTT or 4 packets per RTT accordingly. What the RFC really suggests is: Case 2: 1)Sends DCCP request (saying its CCID is 3) gets DCCP response, sends DCCP ACK, gets RTT estimate. 2)Sets the initial sending rate to 2 packets per RTT or 4 packets per RTT accordingly. Thanks for your help :) Regds Arjuna They're functionally equivalent -- as soon as you get
feedback from the receiver you're next rate is 2 packets/RTT (per RFC3448). For CCID 3, the initial rate is up to 4 packets per second or RTT -- however you wish to look at it -- and after feedback it's up to 8 packets/RTT. Tom P. > -----Original Message----- > From: Arjuna Sathiaseelan [mailto:arjuna.sathiaseelan@xxxxxxxxx] > Sent: Wednesday, August 16, 2006 10:17 AM > To: Phelan, Tom > Cc: 'dccp' working group; Gorry Fairhurst > Subject: Re: CCID 3 - Slow Starting with One packet per second.. > > Hi Tom, > Thanks for your reply :). Yes it does, but I thought it was only > after it has got a RTT sample (which is got by setting the rate to one > packet per SECOND, sending that packet and when the feedback is > received) and then setting to 2 or 4 packets per RTT? RFC 4342 says: > > "[RFC3448], Section 4, specifies an initial sending rate of one packet > per round-trip time (RTT) as follows: The sender initializes the > allowed sending rate to one packet per second. As soon as a feedback > packet is received from the receiver, the sender has a measurement of > the round-trip time and then sets the initial allowed sending rate to > one packet per RTT. However, while the initial TCP window used to be > one segment, [RFC2581] allows an initial TCP window of two segments, > and [RFC3390] allows an initial TCP window of three or four segments > (up to 4380 bytes). [RFC3390] gives an upper bound on the initial > window of min(4*MSS, max(2*MSS, 4380 bytes)). > > Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate > is allowed to be at least two packets per RTT, and at most four > packets per RTT, depending on the packet size. The initial rate is > only allowed to be three or four packets per RTT when, in terms of > segment size, that translates to at most 4380 bytes per RTT." > > Am I confused? :) > > Regds > Arjuna > > On 8/16/06, Phelan, Tom <tphelan@xxxxxxxxxxxx> wrote: > > Hi Arjuna, > > > > CCID3 allows an initial sending rate of at least two and up to four > > packets depending on the packet size (up to 4380 bytes in the initial > > burst of three or four packets). > > > > Tom P. > > > > > -----Original Message----- > > > From: Arjuna Sathiaseelan [mailto:arjuna.sathiaseelan@xxxxxxxxx] > > > Sent: Wednesday, August 16, 2006 5:27 AM > > > To: 'dccp' working group > > > Cc: Gorry Fairhurst > > > Subject: CCID 3 - Slow Starting with One packet per second.. > > > > > > Dear All, > > > I presume that CCID 3 is still following RFC 3448's slow start > > > behaviour of 1 packet per second during the start of the connection, > > > and when the ACK is received for that packet, the INITIAL ALLOWED > > > SENDING RATE is set to 2 packets to 4 packets per RTT appropriately. > > > > > > Now my question is do we still need to follow TFRC's way of starting > > > with one packet per second to determine the RTT estimate? Since, DCCP > > > has its initial three way handshake similar to TCP, can CCID3 use the > > > handshake to determine the RTT and start with an initial allowed > > > sending rate set to 3 or 4 packets accordingly? > > > > > > Based on this paper, using the SYN/ACK, RTT could be accurately > > measured. > > > http://www.acm.org/sigs/sigcomm/ccr/archive/2002/jul02/ccr-2002-3- > > > jiang.pdf > > > > > > I guess starting with one packet per second , induces an additional > > > RTT's worth of delay which may not be good for certain applications > > > such as VoIP running over a satellite network.. > > > > > > Correct me if I am wrong..thanks > > > > > > -- > > > Regards, > > > Arjuna > > > > > > Postdoctoral Researcher > > > Engineering Research Lab, > > > Department of Engineering, > > > University of Aberdeen > > > > > > > -- > Regards, > Arjuna > > Postdoctoral Researcher > Engineering Research Lab, > Department of Engineering, > University of Aberdeen
-- Regards, Arjuna Postdoctoral Researcher Engineering Research Lab, Department of Engineering, University of Aberdeen
