Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-02.txt

From: Kevin Gross <[email-masked]>
Date: Tue, 8 May 2012 14:00:35 -0600

I have now reviewed the draft and have one additional comment:

Section 3.2: Three report types are specified in Interval Metric flag
definition. Only two of these appear to be supported for reporting number
of packets discarded. Suggest removing Sampling option from Interval Metric
flag definition.

I have also answered your question from a while back below. Sorry for the
delay.

On Fri, Apr 20, 2012 at 8:02 PM, Qin Wu <[email-masked]> wrote:

> **
> Hi,
>
> ----- Original Message -----
> *From:* Kevin Gross <[email-masked]>
> *To:* Qin Wu <[email-masked]>
> *Cc:* Varun Singh <[email-masked]> ; [email-masked]
> *Sent:* Friday, April 20, 2012 11:15 PM
> *Subject:* Re: [xrblock] I-D Action:
> draft-ietf-xrblock-rtcp-xr-discard-02.txt
>
> 2. What are examples of other reasons for discarding packets that would
> fall into the 00 category?
>
> [Qin]: I am not aware of that. Kevin, would you like to clarify this a
> little bit?
>

One possibility is sequence number inconsistent with RTP timestamp. Another
is RTP timestamp so far removed from expected that it is difficult to
decide whether to report as too early or too late.

---

From: Qin Wu <[email-masked]>
Date: Wed, 9 May 2012 12:53:37 +0800

----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Wednesday, May 09, 2012 4:00 AM
  Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-02.txt

  Section 3.2: Three report types are specified in Interval Metric flag definition. Only two of these appear to be supported for reporting number of packets discarded. Suggest removing Sampling option from Interval Metric flag definition.

[Qin]:Yes, I agree that the sampling option doesn't apply here. Thank for your suggestion.

  I have also answered your question from a while back below. Sorry for the delay.

    Hi,
      ----- Original Message ----- 
      From: Kevin Gross 
      To: Qin Wu 
      Cc: Varun Singh ; [email-masked] 
      Sent: Friday, April 20, 2012 11:15 PM
      Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-02.txt

      2. What are examples of other reasons for discarding packets that would fall into the 00 category?
    [Qin]: I am not aware of that. Kevin, would you like to clarify this a little bit?

  One possibility is sequence number inconsistent with RTP timestamp. 
[Qin]: RTP timestamp is used for media synchronization. The sequence number is used for packet loss and disordering detection.
The multimedia data can be transmitted as RTP packet with appropriate timestamps and increasing sequence numbers at the sender side,
At the receiver side, the timestamps and sequence number should be tackled separately by application at the transport level and media level.
It is not clear to me how the receiver know the sequence number is inconsistent with RTP timestamp.
Shouldn't the receiver always deem the RTP timestamp with associated sequence number received in the RTP packet acceptable?
 
  Another is RTP timestamp so far removed from expected that it is difficult to decide whether to report as too early or too late.

[Qin]: In burst gap drafts, an implementation-specific time window is used to decide whether to report as too early or too late.
I think such time window is constructed based on the RTP timestamp and jitter buffer/playout buffer. So it doesn't look another new reason
for discarding packets.

______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock

---

From: Kevin Gross <[email-masked]>
Date: Wed, 9 May 2012 08:38:58 -0600

Qin,

Are you claiming that the only reasons receivers discard packets at the
application layer is if they arrive too early or too late?

Kevin Gross

On Tue, May 8, 2012 at 10:53 PM, Qin Wu <[email-masked]> wrote:

> *Cc:* [email-masked]
> *Sent:* Wednesday, May 09, 2012 4:00 AM
> *[Qin]:Yes, I agree that the sampling option doesn't apply here. Thank
> for your suggestion.*
>
>
> *[Qin]: RTP timestamp is used for media synchronization. The sequence
> number is used for packet loss and disordering detection.*
> *The multimedia data can be transmitted as RTP packet with appropriate
> timestamps and increasing sequence numbers at the sender side,*
> *At the receiver side, the timestamps and sequence number should
> be tackled separately by application at the transport level and media level.
> *
> *It is not clear to me how the receiver know the sequence number is
> inconsistent with RTP timestamp.*
> *Shouldn't the receiver always deem the RTP timestamp with associated
> sequence number received in the RTP packet acceptable?*
>
>
> Another is RTP timestamp so far removed from expected that it is difficult
> to decide whether to report as too early or too late.
>
>
> *[Qin]: In burst gap drafts, an implementation-specific time window is
> used to decide whether to report as too early or too late.*
> *I think such time window is constructed based on the RTP timestamp
> and jitter buffer/playout buffer. So it doesn't look another new reason*
> *for discarding packets.*
>
>

---

From: Varun Singh <[email-masked]>
Date: Wed, 9 May 2012 22:23:55 +0300

Hi Kevin, Qin

[commenting only on the latter part of the message]
>> Subject: Re: [xrblock] I-D Action:
> is RTP timestamp so far removed from expected that it is difficult to decide
> whether to report as too early or too late.

While experimenting with scheduling algorithms for Multipath RTP
(MPRTP) we observed that an RTP packet should not be so late or early
that the receiver thinks that the RTP stream was reset, and new
sequence numbers have started. We observed this when we were verifying
the backwards compatibility of an MPRTP sender with a legacy receiver
(Gstreamer and Live555).

So it is possible for a receiving endpoint to be confused and in this
particular case the legacy receiver sent a Discard RLE Report to help
the scheduling algorithm find out which paths the discards occurred on
and correct it.

Now, the question: if these packets should be reported in early, late,
early and late or miscellaneous discards?
I dont have a strong opinion but since the receiver is discarding a
set of RTP packets because it believes the stream was reset, these
kind of discards may fall in the miscellaneous category.

Cheers,
Varun

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 May 2012 10:10:30 +0800

No, as Varun clarified ealier on the list, 
we believe there are other reasons for discard than early, or late arrival of
packets, e.g., duplicate, redundant packets.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Wednesday, May 09, 2012 10:38 PM
  Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-02.txt

  Qin,

  Are you claiming that the only reasons receivers discard packets at the application layer is if they arrive too early or too late?

  Kevin Gross

    ----- Original Message ----- 
      From: Kevin Gross 
      To: Qin Wu 
      Cc: [email-masked] 
      Sent: Wednesday, May 09, 2012 4:00 AM
      Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-02.txt

        Hi,
          ----- Original Message ----- 
          From: Kevin Gross 
          To: Qin Wu

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 May 2012 10:15:00 +0800

----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Kevin Gross" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 10, 2012 3:23 AM
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-02.txt

> kind of discards may fall in the miscellaneous category.

[Qin]: Yes, if the receiver has the intelligence to know the stream was reset is becos
sequence number is inconsistent with RTP timestamp, I agree this kind of reason should
fall in the other reasons for discard than early, or late arrival of
packets, i.e., miscellaneous category you described.

---

From: Kevin Gross <[email-masked]>
Date: Thu, 10 May 2012 08:39:20 -0600

OK, but the current drafts of draft-ietf-xrblock-rtcp-xr-discard
and draft-ietf-xrblock-rtcp-xr-discard-rle-metrics do not have an 'other'
category. I'm not necessarily requesting that one be added but if it is
not, it should be mentioned in the draft(s) that there
are potentially other reasons besides too early or too late that packets
may be discarded. In section
5.2, draft-ietf-xrblock-rtcp-xr-discard-rle-metrics, claims that there
aren't other reasons.

Also,
the introduction to draft-ietf-xrblock-rtcp-xr-discard-rle-metrics gave me
a good overview of what loss reporting is available in RTCP. It would be
nice to include such an overview in draft-ietf-xrblock-rtcp-xr-discard.
(One might even consider combining these two into a single draft.)

Kevin Gross

On Wed, May 9, 2012 at 8:15 PM, Qin Wu <[email-masked]> wrote:

> Another
> decide

---

From: Varun Singh <[email-masked]>
Date: Thu, 10 May 2012 21:24:24 +0300

Hi Kevin,

Comments inline

> and draft-ietf-xrblock-rtcp-xr-discard-rle-metrics do not have an 'other'

Originally:
In the Discard-RLE, the E bit is set for discards due to early arrival
and 0 otherwise. Later in the same draft it says that the E bit can be
used for distinguishing between early (E=1) and late discards (E=0).
This may be a bit ambiguous if the sender wants to distinguish between
late (E=0) and miscellaneous (also E=1) types of discards.

Now:
There was a requirement put forth to report both the Late and Early
packets in one report and leads to the discussion in this thread. Just
re-iterating my proposal:

00: misc (not because of early or late)
01: early
10: late
11: early+late (or should it be sum of all discards?)

I am now wondering if the 11: should be sum of all discards instead of
just the sum of early and late discards.
Because, the burst gap discard depends on the discard draft and
requires the total packets discarded (not early+late). The Burst gap
discard draft should also clarify what E-bit setting should be
expected for the discard packet.

> category. I'm not necessarily requesting that one be added but if it is not,
> it should be mentioned in the draft(s) that there
> are potentially other reasons besides too early or too late that packets may
> be discarded. In section
See above, but I will update the discard RLE draft based on the
discussion in this thread.

> Also,
> the introduction to draft-ietf-xrblock-rtcp-xr-discard-rle-metrics gave me a
> good overview of what loss reporting is available in RTCP. It would be nice
> to include such an overview in draft-ietf-xrblock-rtcp-xr-discard. (One
> might even consider combining these two into a single draft.)
>

The discarded bytes and discarded packets could be merged, because
they are similar types of reports. However, the discard RLE and burst
gap discard reports are different enough to be in a separate drafts.

Regards,
Varun

---

From: Qin Wu <[email-masked]>
Date: Thu, 31 May 2012 20:21:22 +0800

Also, the introduction to draft-ietf-xrblock-rtcp-xr-discard-rle-metrics gave me a good overview of what loss reporting is available in RTCP. It would be nice to include such an overview in draft-ietf-xrblock-rtcp-xr-discard. (One might even consider combining these two into a single draft.)

[Qin]: Sorry for late reply. one more clarification, is, draft-ietf-xrblock-rtcp-xr-discard was early developed before draft-ietf-xrblock-rtcp-xr-discard-rle-metrics. 
And draft-ietf-xrblock-rtcp-xr-discard-rle-metrics adds dependency to draft-ietf-xrblock-rtcp-xr-discard draft and has already clarified the relationship with
 discard draft in its introduction section.