Hi Arjuna et al.,
Arjuna Sathiaseelan wrote:
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
My reading of the RFCs is as follows.
- The initial RTT estimate, before any RTT sample is received, is set to 1 second.
- The initial sending rate is 2-4 packets/RTT, depending on packet size. (At
least 2 packets, and up to 4 packets if the sum of packet sizes is <=4380B.)
- Thus, before any RTT samples are received, the initial sending rate is 2-4
packets/second.
- The three-way handshake MAY be used to obtain an initial RTT estimate.
- In addition I would say that any data included on the DCCP-Request SHOULD be
counted in the 2-4 p/RTT.
Eddie
