Re: [dccp] A question about CCID 3

[Sara Landström <sara.landstrom at ltu.se>]

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. 

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.

> My second question is that what is included in the packet size in TCP
> throughput equation? Is it only the size of user data segment of
> DCCP-Data packet or are DCCP and IP packet headers also included in?
> And the same question about receive rate calculation in the DCCP
> receiver. Are DCCP and IP packet headers included in when calculating
> receive rate?
>  
It should only be the payload of the DCCP packet that is considered in 
the throughput equation and the receive rate computation.

I need more details about your scenario to be able to give you better 
help, but I hope this will help you somewhat.

Regards,
Sara Landström

> Sampo Luukkainen
>
>