[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dccp] A question about CCID 3
Hi,
My comments are inline.
On Thu, 4 Aug 2005, Sara Landström wrote:
> Hi Sampo,
> my comments are inline.
>
> Sampo K I Luukkainen wrote:
>
> >Hi,
> >
> >I encountered a situation where CCID 3 behaves in a strange way as far
> >as I understood how it should work. The situation is here:
> >
> >There is a single half connection between DCCP sender and DCCP receiver
> >using CCID 3. ECN is not used. Packets are sent in the following way
> >during the connection:
> >
> > DCCP sender DCCP receiver
> > ----------- -------------
> >1. DCCP-Data (seqnum n) ---> lost
> >2. DCCP-Data (seqnum n+1) --->
> >3. DCCP-Data (seqnum n+2) --->
> >4. <--- DCCP_Ack (seqnum p)
> >5. DCCP-Ack (seqnum n+3) --->
> >6. <--- DCCP_Ack (seqnum p+1)
> >
> >
> >1. DCCP sender sends a data packet which is lost.
> >2. and 3. DCCP receiver receives a packet
> > (DCCP-Data, DCCP-DataAck or DCCP-Ack)
> >4. DCCP receiver sends an ACK to the DCCP sender
> >5. DCCP receiver receives a DCCP-Ack.
> > * now DCCP receiver detects a new loss event as three packets with
> > a higher sequence number have reached the destination after the
> > lost packet (seqnum n).
> > (RFC 3448 states that:
> > "The loss of a packet is detected by the arrival of at least three
> > packets with a higher sequence number than the lost packet.")
> >6. DCCP receiver sends a DCCP-Ack to the DCCP sender, because a new
> > loss event was detected.
> > (RFC 3448 states that:
> > "A feedback packet should also be sent whenever a
> > new loss event is detected without waiting for the end of an RTT")
> >
> > Profile for DCCP Congestion Control ID 3 states about Receive Rate
> > Option that:
> > "This option MUST be sent by the data receiver on all required
> > acknowledgements. Its four data bytes indicate the rate at which
> > the receiver has received data since it last sent an
> > acknowledgement, in bytes per second."
> > and
> > "The feedback packets from the receiver contain a Receive Rate
> > option specifying the rate at which data packets arrived at the
> > receiver since the last feedback packet."
> >
> > In the example no data packets have been received by the DCCP
> > receiver since the last sent acknowledgement (seqnum p).
> > My question is that should the value of Receive Rate Option really
> > be 0 in the DCCP-Ack (seqnum p+1)? This means practically that
> > the DCCP sender must stop sending data as a result of a single packet
> > loss. Or have I misunderstood something?
> >
> >
> I don't completely understand your scenario, because you say that no
> packets have been received by the data receiver since the last ack was
> sent. This means that you shouldn't send any ack. See the following
> exerpt from CCID3:
>
> 10.3. Sending Feedback Packets
>
> In CCID 3, the window counter is used by the receiver to decide when
> to send feedback packets. RFC 3448 (Sections 6.1 and 6.2) specifies
> that the TFRC receiver sends a feedback packet when the new loss
> event rate p is less than the old value. This rule is followed by
> CCID 3.
>
> In addition, RFC 3448 (Section 6.2) specifies that the receiver uses
> a feedback timer to decide when to send additional feedback packets.
> If the feedback timer expires, and data packets have been received
> since the previous feedback was sent, then the receiver sends a
> feedback packet.
>
> If packet number (n+3) does reach the receiver after ack (p) is sent then
> the loss of packet n is discovered and the receiver computes the loss rate that
> would give the receive rate observed during the last rtt, see below from RFC3448. The receive rate should
> to be put into the receive rate option is the size of the only packet that arrived divided by the time that has passed
> since the last ack was sent.
The problem in the scenario is that packet number (n+3) is DCCP-Ack
which doesn't carry any payload data. Because it's the only packet
which has been received after ack (p) is sent, no payload data has
been received since the last ack was sent. The value of receive
rate option included in ack (p+1) is then 0.
>
> 6.3.1. Initializing the Loss History after the First Loss Event
>
> The number of packets until the first loss can not be used to compute
> the sending rate directly, as the sending rate changes rapidly during
> this time. TFRC assumes that the correct data rate after the first
> loss is half of the sending rate when the loss occurred. TFRC
> approximates this target rate by X_recv, the receive rate over the
> most recent round-trip time. After the first loss, instead of
> initializing the first loss interval to the number of packets sent
> until the first loss, the TFRC receiver calculates the loss interval
> that would be required to produce the data rate X_recv, and uses this
> synthetic loss interval to seed the loss history mechanism.