[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dccp] A question about CCID 3
Hi,
Another question about the same scenario. Consider that the
lost packet (number n) is the first loss of the connection.
How should loss event rate be calculated when the first
loss is detected? In the scenario the first loss is detected
when packet number n+3 (DCCP-Ack) arrives. The most recent
receive rate calculated by the DCCP receiver is then 0 as
described before. RFC 3448 states that:
"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.
TFRC does this by finding some value p for which the
throughput equation in Section 3.1 gives a sending rate
within 5% of X_recv, given the current packet size s and
round-trip time R. The first loss interval is then set to
1/p."
There is no solution for the TCP throughput equation when the
sending rate is 0 (s > 0). The sending rate is the lowest
when p=1. However, this is usually too conservative.
Sampo
On Thu, 4 Aug 2005, Eddie Kohler wrote:
> Hi Sampo, some points.
>
> (1) The TFRC equation has a lower bound on X of s/t_mbi (one packet
> every 64 seconds), so the sending rate will never literally drop to 0.
>
> (2) The parameter X_recv does not necessarily equal the value of the
> last Receive Rate option, since X_recv is supposed to be measured
> over a round trip time, and Receive Rate is not. (Nevertheless, I
> expect many senders will simply use the last X_recv.)
>
> (3) More fundamentally, any Ack packet that acknowledges no data
> packets *should not* contain a Receive Rate option. The TFRC
> mechanism expects that if the sender is not sending, the receiver is
> not acknowledging. The "nofeedback" timer mechanism is used to
> reduce the cached X_recv appropriately. Reducing it to 0 is far too
> conservative.
>
> I would suggest that implementations should probably ignore Receive
> Rate(0) options. This would be more robust to acknowledgers that
> include Receive Rate(0) options inappropriately.
>
> Sally??
>
> Eddie
>
>
>
>
> On Aug 4, 2005, at 4:03 AM, Sampo K I Luukkainen wrote:
>
> > 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.
> >>
> >
> >
> >
>
>
>