Subject: Re: [AVT] Fw: New version of draft-wu-avt-retransmission-supression-rtp-02

From: Qin Wu <[email-masked]>
Date: Sat, 26 Jun 2010 11:13:33 +0800

Hi, Weesan:
Thank for your detailed review and valuable comments offline. Please see my feedback belows.

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: "Qin Wu" <[email-masked]>
Sent: Saturday, June 26, 2010 3:18 AM
Subject: Re: Fw: [AVT] New version of draft-wu-avt-retransmission-supression-rtp-02

> Hi Qin,
> 
> I've read through the draft once, and more in some sections.  Please
> find the end of this email a diff of the draft.  I'd made some changes
> of the wordings and corrected some grammar errors.  Please feel free
> to use them or ignore them :) I also included my comments/questions
> inline.
> 
> -- 
> Thanks,
> -WeeSan
> 
> *** draft-wu-avt-retransmission-supression-rtp-02.txt.orig 2010-06-25 10:10:14.000000000 -0700
> --- draft-wu-avt-retransmission-supression-rtp-02.txt 2010-06-25 12:07:39.000000000 -0700
> ***************
> *** 173,215 ****
>  
>     RTP retransmission is an effective packet loss recovery technique for
>     real-time applications with relaxed delay bounds [RFC4588],e.g.,
> !    streaming media.  The conventional RTCP feedback (NACK) message which
> !    conveys the RTP sequence number of the lost packets can be used to
>     request the sender to compensate the missing RTP packets based on the
>     RTP sequence number of these packets [RFC4585].
>  
> !    However, in lots of multicast environments, packet loss occurs in the
>     upstream link or downstream aggregate link of the intermediate
> !    network element (e.g., Retransmission server, Distribution Source)
>     due to oversaturated network link, faulty networking hardware or
>     corrupted packets rejected in-transit.  It may result in NACK
>     implosion targeting at the same sender, i.e., massive NACK request to
>     the same multicast sender for retransmission of the same RTP packets
> !    which is also known as "NACK storm" described in [DVB-IPTV]To
>     increase the robustness to the loss of a NACK or of a retransmission
>     packet, a receiver may also send multiple NACKs for the same packet
>     which may aggravate the NACK implosion.
>  
> !    A similar use case is video Fast Update request storm occurs in the
>     conversational multimedia scenarios.  In this case, packet loss may
> !    happen in the upstream link of intermediate network element like
>     Multipoint Control Unit(MCU) which results in massive fast update
>     request (i.e., Full Intra Request(FIR) described in [RFC5104]) from
>     receivers to the same media sender.
>  
>     As these feedback storms progress (e.g., NACK implosion or Fast
>     update implosion), the network may be overwhelmed with constant
> !    feedback traffic, in the worsening case, RTCP feedback storm poses a
>     risk of increasing network congestion, with excessive traffic and
> !    degrading network performance, this can eventually lead to a complete
> !    loss of network connectivity as such feedback packets proliferate,
> !    the network may become unusable.
> ! 
> !    In order to solve this, the current text in [RFC5760] allows the
> !    distribution source to filter out the NACK messages while this
> !    document propose an option to let the receivers know that Feedback
> !    for packet loss is not needed in the specified cases. i.e.,
>     generating one new generic RTCP receiver report message, which
>     reflects the packet receipt/loss events and feedback suppression
>     early indication events before the receiver detects an original
>     packet loss and all the packet loss repair methods are applied.
> --- 175,221 ----
>  
>     RTP retransmission is an effective packet loss recovery technique for
>     real-time applications with relaxed delay bounds [RFC4588],e.g.,
> !    streaming media.  The conventional RTCP feedback (NACK) message, which
> !    conveys the RTP sequence number of the lost packets, can be used to
>     request the sender to compensate the missing RTP packets based on the
>     RTP sequence number of these packets [RFC4585].
>  
> !    However, in a network with many multicast streams, packet loss occurs in the
>     upstream link or downstream aggregate link of the intermediate
> !    network elements (e.g., Retransmission server, Distribution Source)
>     due to oversaturated network link, faulty networking hardware or
>     corrupted packets rejected in-transit.  It may result in NACK
>     implosion targeting at the same sender, i.e., massive NACK request to
>     the same multicast sender for retransmission of the same RTP packets
> !    which is also known as "NACK storm" described in [DVB-IPTV].  To
>     increase the robustness to the loss of a NACK or of a retransmission
>     packet, a receiver may also send multiple NACKs for the same packet
>     which may aggravate the NACK implosion.
>  
> !    Similarly, the video Fast Update request storm can occur in the
>     conversational multimedia scenarios.  In this case, packet loss may
> !    happen in the upstream link of intermediate network elements like
>     Multipoint Control Unit(MCU) which results in massive fast update
>     request (i.e., Full Intra Request(FIR) described in [RFC5104]) from
>     receivers to the same media sender.
>  
>     As these feedback storms progress (e.g., NACK implosion or Fast
>     update implosion), the network may be overwhelmed with constant
> !    feedback traffic, in a worst case scenario, RTCP feedback storm can
> !    pose a
>     risk of increasing network congestion, with excessive traffic and
> !    degrading network performance.  This can eventually lead to a complete
> !    loss of network connectivity as such feedback packets proliferate.
> !    The network may become unusable as a result.
> ! 
> !    In order to solve this, [RFC5760] allows the
> !    source to filter out the NACK messages.  This document enhances that
> !    and proposes an option to let the receivers know that Feedback
> !    for packet loss is not needed in some specified cases. i.e.,
>     generating one new generic RTCP receiver report message, which
> + 
> +    [weesan]: who generates the report?
> + 

[Qin]: We have two cases to see who generate the report.
In the simple Feedback model,  the dedicated receiver for loss report will be responsible for generating the report.
In the Distribution Source Feedback Summary Model, the dedicate receiver can generate this new report or use
the existing NACK message and then distribution source will summarize the new report or NACK message from the dedicated reciever into one
compound report and send it to the multicast group.
So here we don't mention who generate the report.

>     reflects the packet receipt/loss events and feedback suppression
>     early indication events before the receiver detects an original
>     packet loss and all the packet loss repair methods are applied.
> ***************
> *** 238,251 ****
>     type.  When the packet loss is detected and initial latency is
>     tolerable, in the upstream direction towards the sender, the
>     intermediate node may ask for retransmission of the lost packet from
> !    the sender or ask for the correct decoder refresh point, meanwhile,
>     in the downstream direction from the sender, the intermediate node
>     may convey Feedback Suppression Indication to all the receivers
> !    concerned to indicate that the receiver should not to transmit
>     feedback messages.  When the sender receives the request from the
>     intermediate node, the sender resends the missing packets to the
> !    receiver via RTP using retransmission payload format [RFC4588]or a
> !    new refresh point for FIR Initiator [RFC5104]
>  
>     Similar to RTCP NACK, the Feedback Storm Suppression also conveys the
>     packet receipt/loss events at the packet level and considers missing
> --- 244,260 ----
>     type.  When the packet loss is detected and initial latency is
>     tolerable, in the upstream direction towards the sender, the
>     intermediate node may ask for retransmission of the lost packet from
> !    the sender or ask for the correct decoder refresh point.  Meanwhile,
>     in the downstream direction from the sender, the intermediate node
>     may convey Feedback Suppression Indication to all the receivers
> !    indicating that the receivers should not transmit
>     feedback messages.  When the sender receives the request from the
>     intermediate node, the sender resends the missing packets to the
> !    receiver via RTP using retransmission payload format [RFC4588] or a
> !    new refresh point for FIR Initiator [RFC5104].
> ! 
> !    [weesan] This violates the end-to-end principles.  The intermediate
> !    nodes are supposed to be simple and dump.

[Qin]: No, this document follows the simple Feedback model and Distribution Source model
described in RFC5760. In this model, the feedback will be integrated into Distribution source and responsible for
sending the original report packet or sumaries of these report to the distribution source, the distribution source is
very simple and just relay the packets to the media sender and group using SSM. 

>     Similar to RTCP NACK, the Feedback Storm Suppression also conveys the
>     packet receipt/loss events at the packet level and considers missing
> ***************
> *** 255,274 ****
>     intermediate node and sent to the corresponding receivers.
>  
>     Note that the feedback storm suppression should collectively work
> !    together with feedback to repair the lost source packets.  Thus, the
> !    delay for the receiver to recover from the packet loss can be reduced
>     and the risk of increasing network congestion can be mitigated or
>     diminished.  The receiver may send a Feedback message before
>     receiving the indication but will not need to resend the Feedback
>     message after receiving the indication.  Also the idea of Feedback
>     Storm Suppression can be further extended when a distributed content
>     distribution network (CDN) are considered.  That is to say several
> !    intermediate node and media senders may constitute hierarchical
> !    model.  In this distributed content distribution environment, the
> !    Feedback Storm Suppression not only can be used to suppress all the
> !    receivers behind itself not to send packet loss request but also
> !    suppress the neighboring node not to send packet loss request for the
> !    missing packets via unicast.  How the neighboring node is discovered
>     is beyond scope of this document.
>  
>     This document registers two new RTCP receiver report messages for
> --- 264,283 ----
>     intermediate node and sent to the corresponding receivers.
>  
>     Note that the feedback storm suppression should collectively work
> !    together with feedback to repair the lost packets from the source.  Thus, the
> !    delay for the receiver to recover from the packet loss can be reduced,
>     and the risk of increasing network congestion can be mitigated or
>     diminished.  The receiver may send a Feedback message before
>     receiving the indication but will not need to resend the Feedback
>     message after receiving the indication.  Also the idea of Feedback
>     Storm Suppression can be further extended when a distributed content
>     distribution network (CDN) are considered.  That is to say several
> !    intermediate nodes and media senders may constitute hierarchical
> !    model.  In this distributed environment, not only can the
> !    Feedback Storm Suppression suppress all the
> !    receivers downstream from sending packet loss requests, but also it
> !    suppress the neighboring nodes from sending packet loss requests for the
> !    missing packets via unicast.  How the neighboring nodes are discovered
>     is beyond scope of this document.
>  
>     This document registers two new RTCP receiver report messages for
> ***************

[Qin]: Good, accepted.

> *** 285,298 ****
>     with these loss-repair methods for every packet they receive or for a
>     set of specific packets they have received.
>  
> !    Note: The draft focus on the SSM case.  The video MCU has similar
> !    issue with packet loss since the MCU need to multi-unicast the stream
> !    from the source to all participants and may have the same problem
>     when packets are lost between the source and the MCU.  If the
>     consensus is that the only relevant use case is the NACK implosion we
> !    can look at adding semantics to NACK for this case.  Otherwise we can
>     expand the text on the video packet loss case.
>  
>  
>  2.  Terminology
>  
> --- 294,309 ----
>     with these loss-repair methods for every packet they receive or for a
>     set of specific packets they have received.
>  
> !    Note: This draft focuses on the SSM case.  The video MCU has similar
> !    issue with packet loss since the MCU needs to multi-unicast the stream
> !    from the source to all the participants and may have the same problem
>     when packets are lost between the source and the MCU.  If the
>     consensus is that the only relevant use case is the NACK implosion we
> !    can look into adding semantics to NACK for this case.  Otherwise we can
>     expand the text on the video packet loss case.
>  
> +    [weesan] I believe this will be edited out in the final draft?
> + 

[Qin]: You are right. Since video MCU case has similar issue as SSM case,
we need consesue to see whether we need to address this similar issue for video 
MCU case as well, which will be discussed in the upcoming IETF meeting.
Thank for your pointing this out.

>  2.  Terminology
>  
> ***************
> *** 303,328 ****
>     Upstream RTP Client:
>  
>        The RTP Client located in the upstream from the distribution
> !       source as described in [DVB-IPTV].  This Client is able to detect
>        upstream packet loss impacting all the RTP receivers serviced by
>        the distribution source and receiving SSM service.
>     Immediate reporting RTP Client:
>  
>        The RTP Client located in the downstream aggregate link from the
> !       distribution source as described in [DVB-IPTV].  This Client is
>        able to detect downstream packet loss in the aggregate link
>        impacting all the RTP receivers serviced by the distribution
>        source and receiving SSM service.
>     Loss Reporter:
>  
>        The Loss Reporter is one logical function which is used to detect
>        the packet loss at the RTP layer and report it to the distribution
>        source.  The function of the loss reporter may be collocated or
>        integrated in the same entity.  In this case, for a session
> !       defined as having a Distribution Source A, on ports n for the RTP
> !       channel and k for the RTCP channel, the unicast RTCP Feedback
>        Target is identified by an IP address of Distribution Source A on
> !       port k.  The loss reporter MAY also be implemented in one or more
>        entities different from the Distribution Source.  In this case,
>        the loss reporter may be an upstream RTP client or immediate
>        reporting RTP client located in the downstream aggregate link of
> --- 314,341 ----
>     Upstream RTP Client:
>  
>        The RTP Client located in the upstream from the distribution
> !       source as described in [DVB-IPTV].  This client is able to detect
>        upstream packet loss impacting all the RTP receivers serviced by
>        the distribution source and receiving SSM service.
> + 
>     Immediate reporting RTP Client:
>  
>        The RTP Client located in the downstream aggregate link from the
> !       distribution source as described in [DVB-IPTV].  This client is
>        able to detect downstream packet loss in the aggregate link
>        impacting all the RTP receivers serviced by the distribution
>        source and receiving SSM service.
> + 
>     Loss Reporter:
>  
>        The Loss Reporter is one logical function which is used to detect
>        the packet loss at the RTP layer and report it to the distribution
>        source.  The function of the loss reporter may be collocated or
>        integrated in the same entity.  In this case, for a session
> !       defined as having a Distribution Source A, on ports N for the RTP
> !       channel and K for the RTCP channel, the unicast RTCP Feedback
>        Target is identified by an IP address of Distribution Source A on
> !       port K.  The loss reporter MAY also be implemented in one or more
>        entities different from the Distribution Source.  In this case,
>        the loss reporter may be an upstream RTP client or immediate
>        reporting RTP client located in the downstream aggregate link of

[Qin]: Okay.

> ***************
> *** 341,361 ****
>  
>     As described in [RFC5760], one or more Media Senders send RTP packets
>     to the Distribution Source.  The Distribution Source relays the RTP
> !    packets to the receivers using a source-specific multicast
> !    arrangement.  In case of upstream packet loss or downstream aggregate
>     link packet loss, the Loss reporter located in the upstream link or
>     downstream aggregate link may send extended receiver report described
>     in section 6 indicating the packet loss to the distribution source.
> !    And then the distribution source creates packet loss suppression
>     report and transmits it to all the RTP receivers, using source-
>     specific multicast.  The distribution source can ask for
>     retransmission of the lost packets from the media sender on behalf of
> !    all the RTP receivers.  Upon receiving the lost packet, the
>     distribution source forwards them to all the receivers which are
>     impacted by packet loss.
>  
>     When the loss reporter(s) are collocated with distribution source,
> !    redistribution of packet loss report is trivial.  In such case, loss
>     reporter should detect contiguous packet loss coming from upstream
>     link by checking sequence number of RTP packets.  Also the loss
>     reporter may detect contiguous packet loss occurring in the
> --- 354,375 ----
>  
>     As described in [RFC5760], one or more Media Senders send RTP packets
>     to the Distribution Source.  The Distribution Source relays the RTP
> !    packets to the receivers using a source-specific multicast (SSM).
> !    In case of upstream packet loss or downstream aggregate
>     link packet loss, the Loss reporter located in the upstream link or
>     downstream aggregate link may send extended receiver report described
>     in section 6 indicating the packet loss to the distribution source.
> !    And then the distribution source creates a packet loss suppression
>     report and transmits it to all the RTP receivers, using source-
>     specific multicast.  The distribution source can ask for
>     retransmission of the lost packets from the media sender on behalf of
> !    all the RTP receivers.  Upon receiving the lost packets, the
>     distribution source forwards them to all the receivers which are
>     impacted by packet loss.
>  
>     When the loss reporter(s) are collocated with distribution source,
> !    redistribution of packet loss report is trivial.  In this case, the
> !    loss
>     reporter should detect contiguous packet loss coming from upstream
>     link by checking sequence number of RTP packets.  Also the loss
>     reporter may detect contiguous packet loss occurring in the
> ***************

[Qin]: Okay.

> *** 425,431 ****
>     particular media sender and the Feedback Target is collocated with
>     Distribution source.  The communication between the Media sender and
>     the distribution source is compliant with the ways described in
> !    [RFC5760].  Also besides following the configuration information
>     described in [RFC5760], the additional configuration information
>     should be supplied as follows:
>  
> --- 439,445 ----
>     particular media sender and the Feedback Target is collocated with
>     Distribution source.  The communication between the Media sender and
>     the distribution source is compliant with the ways described in
> !    [RFC5760].  In addition to the information
>     described in [RFC5760], the additional configuration information
>     should be supplied as follows:
>  
> ***************

[Qin]: Good rewording. Thanks.

> *** 451,457 ****
>  
>  4.  Simple Feedback Model
>  
> !    In the simple Feedback Model, the Loss reporter(s) are disjoint from
>     distribution source.  In this case, the upstream client or immediate
>     reporting receiver may be chosen as the loss reporter.  Also in this
>     model, the distribution source will include the support for
> --- 465,472 ----
>  
>  4.  Simple Feedback Model
>  
> !    In the simple Feedback Model, the Loss reporter(s) are disjoint
> !    from the
>     distribution source.  In this case, the upstream client or immediate
>     reporting receiver may be chosen as the loss reporter.  Also in this
>     model, the distribution source will include the support for
> ***************

[Qin]: Okay.

> *** 463,469 ****
>     reporter observes RTP packets from a Media Sender are not consecutive
>     by checking the sequence number of packets, the Loss reporter MUST
>     use the same packet types as traditional RTCP feedback described in
> !    [RFC3550]and generate Receiver Feedback Report with information on
>     the RTP sequence number of the lost packets and suppression early
>     indication event.  When a receiver is eligible to transmit, it MUST
>     send this Report packet to the distribution source via unicast
> --- 478,484 ----
>     reporter observes RTP packets from a Media Sender are not consecutive
>     by checking the sequence number of packets, the Loss reporter MUST
>     use the same packet types as traditional RTCP feedback described in
> !    [RFC3550] and generate Receiver Feedback Report with information on
>     the RTP sequence number of the lost packets and suppression early
>     indication event.  When a receiver is eligible to transmit, it MUST
>     send this Report packet to the distribution source via unicast
> ***************

[Qin]: Okay.

> *** 481,492 ****
>     If there are a couple of loss reporters looking at the same RTP
>     stream, then the loss may be identified by all and they will all send
>     requests for the same packet loss.  In this case, the distribution
> !    source MUST filter the duplicated packet loss request out and only
>     forward one copy of the receiver Feedback report packet from the
>     first loss reporter to the group impacted by packet loss.
>  
> !    Because this unicast Receiver Feedback Report is used to let the
> !    receivers/hosts know that Feedback for packet loss is not needed and
>     should not be sent to the media sender(s).  If the Media Sender(s)
>     are part of the SSM group for RTCP packet reflection, the
>     Distribution Source MUST filter this packet out.  If the Media
> --- 496,511 ----
>     If there are a couple of loss reporters looking at the same RTP
>     stream, then the loss may be identified by all and they will all send
>     requests for the same packet loss.  In this case, the distribution
> !    source MUST filter out the duplicated packet loss requests and only
>     forward one copy of the receiver Feedback report packet from the
>     first loss reporter to the group impacted by packet loss.
>  
> !    [weesan] Can the same packet lost report from multiple loss
> !    reporters be further supressed?  eg. send a packet and ask all loss
> !    reporters but one to backoff a little.

[Qin]: Of course we can. As described in the the secton 4"Simple Feedback Model" and section 5 "Distribution Source Summary Model",
"
   If there are a couple of loss reporters looking at the same RTP
   stream, then the loss may be identified by all and they will all send
   requests for the same packet loss.  In this case, the distribution
   source MUST filter out the duplicated information from various loss
   reporters and only append one copy of such information to the summary
   report.

"
Therefore it is easy to suppress all the duplicated report at the distriubtion source based on RTCP port
and filter them out.

> !    Because this unicast Receiver Feedback Report is used to inform the
> !    receivers/hosts that Feedback for packet loss is not needed and
>     should not be sent to the media sender(s).  If the Media Sender(s)
>     are part of the SSM group for RTCP packet reflection, the
>     Distribution Source MUST filter this packet out.  If the Media

[Qin]: Okay.

> ***************
> *** 494,502 ****
>     Distribution Source MUST not forward this RTCP packets received from
>     the receivers to the Media Sender(s).
>  
> !    When the host receives the RTCP packet, if the host understands this
> !    message it will not send packet loss request (e.g., NACK) for the
> !    missing packets reported in the message and will accept a
>  
>  
>  
> --- 513,521 ----
>     Distribution Source MUST not forward this RTCP packets received from
>     the receivers to the Media Sender(s).
>  
> !    When a host receives the RTCP packet and if the host understands this
> !    message, it will not send packet loss request (e.g., NACK) for the
> !    missing packets reported in the message, and it will accept a
>  
[Qin]: Okay.
  
> ***************
> *** 505,513 ****
>  Internet-Draft         Feedback Storm Suppression              June 2010
>  
>  
> !    retransmission stream transmitted from the Distribution Source.  If
> !    it did not understand this new message, the host may send packet loss
> !    request(e.g., NACK messages) to the specified media sender.  When the
>     distribution source receives the packet loss request from the hosts,
>     the distribution source MUST filter it out until the Retransmission
>     stream is ready in the Distribution Source.
> --- 524,532 ----
>  Internet-Draft         Feedback Storm Suppression              June 2010
>  
>  
> !    retransmission stream transmitted from the Distribution Source.
> !    Otherwise, the host may send packet loss
> !    request to the specified media sender.  When the
>     distribution source receives the packet loss request from the hosts,
>     the distribution source MUST filter it out until the Retransmission
>     stream is ready in the Distribution Source.
> ***************

[Qin]: Okay.

> *** 517,529 ****
>  
>     In the distribution source feedback summary model, the distribution
>     source will include the support for retransmission as part of the
> !    offered SDP and will expect such support from the Media Sender, also
> !    the Loss reporter instance may be integrated in the distribution
>     source or may be separated from the distribution source.  In some
>     cases, several loss reporter instances for the same session can exist
>     at the same time, e.g., one loss reporter instance (loss reporter A)
> !    is implemented in the upstream client A, one loss reporter instance
> !    (loss reporter B) is implemented in the upstream client B, another
>     loss reporter instance for the same session (loss reporter C) is
>     integrated in the distribution source.  In this section, we focus on
>     this generic case to discuss the distribution Source Feedback Summary
> --- 536,548 ----
>  
>     In the distribution source feedback summary model, the distribution
>     source will include the support for retransmission as part of the
> !    offered SDP and will expect such support from the Media Sender,
> !    The Loss reporter instance may be integrated in the distribution
>     source or may be separated from the distribution source.  In some
>     cases, several loss reporter instances for the same session can exist
>     at the same time, e.g., one loss reporter instance (loss reporter A)
> !    is implemented in the upstream client A, another loss reporter instance
> !    (loss reporter B) is implemented in the upstream client B, a third
>     loss reporter instance for the same session (loss reporter C) is
>     integrated in the distribution source.  In this section, we focus on
>     this generic case to discuss the distribution Source Feedback Summary

[Qin]: Okay.

> ***************
> *** 541,558 ****
>     In order to
>     reduce the processing load at the distribution source, the individual
>     instance of Loss Reporter may provide preliminary summarization
>     report.
>  
> !    In some case, the distribution source may receive RTCP NACK messages
>  
>  
>  
> --- 560,582 ----
> !    In order to
>     reduce the processing load at the distribution source, the individual
>     instance of Loss Reporter may provide preliminary summarization
>     report.
>  
> !    In some cases, the distribution source may receive RTCP NACK messages
>  

[Qin]: Okay.
  
> ***************
> *** 563,569 ****
>  
>     from the receivers behind the Distribution Source before the
>     distribution source detects the packet loss which may cause potential
> !    Feedback implosion.  In such case, the distribution source may filter
>     them out if it already sent a packet loss request for the missing
>     packet to the media sender.  When the distribution source confirms
>     packet loss reported by the receiver, the distribution source
> --- 587,593 ----
>  
>     from the receivers behind the Distribution Source before the
>     distribution source detects the packet loss which may cause potential
> !    Feedback implosion.  In such cases, the distribution source may filter
>     them out if it already sent a packet loss request for the missing
>     packet to the media sender.  When the distribution source confirms
>     packet loss reported by the receiver, the distribution source
> ***************

[Qin]: Good, Accepted.

> *** 586,597 ****
>     reporters and only append one copy of such information to the summary
>     report.
>  
> !    When the host receives the RTCP packet, if the host understands this
> !    message it will not send packet loss request (e.g., NACK) for the
> !    missing packets reported in the message and will accept a
> !    retransmission stream transmitted from the Distribution Source.  If
> !    it did not understand this new message, the host may send packet loss
> !    request(e.g., NACK messages) to the specified media sender.  When the
>     distribution source receives the packet loss request from the hosts,
>     the distribution source MUST filter it out until the Retransmission
>     stream is ready in the Distribution Source.
> --- 610,621 ----
>     reporters and only append one copy of such information to the summary
>     report.
>  
> !    When a host receives the RTCP packet and if the host understands this
> !    message, it will not send packet loss request (e.g., NACK) for the
> !    missing packets reported in the message, and it will accept a
> !    retransmission stream transmitted from the Distribution Source.  
> !    Otherwise, the host may send packet loss
> !    request to the specified media sender.  When the
>     distribution source receives the packet loss request from the hosts,
>     the distribution source MUST filter it out until the Retransmission
>     stream is ready in the Distribution Source.
> ***************

[Qin]: Okay.

> *** 637,647 ****
> --- 661,673 ----
>  
>        The SSRC value of the media sender that is requested to send the
>        lost packet.
> + 
>     Starting Sequence Number (SSN):16bits
>  
>        The SSN field is used to specify the contiguous packet loss.  The
>        SSN field refers to the RTP sequence number of the first lost
>        packet.
> + 
>     Last Sequence Number (LSN): 16 bits
>  
>        The LSN field is used to specify the contiguous packet loss.  The
> ***************
> *** 687,696 ****
> --- 713,724 ----
>  
>        The SSRC value of the media sender that is requested to send a
>        decoder refresh point.
> + 
>     Seq nr:8bits  Command sequence number.  The sequence number space is
>        unique for each pairing of the SSRC of command source and the SSRC
>        of the command target.  The sequence number SHALL be increased by
>        1 modulo 256 for each new command.
> + 
>     Reserved: 24 bits
>  
>        All bits SHALL be set to 0 by the sender and SHALL be ignored on
> ***************
> *** 699,706 ****

[Qin]: It is a typo, will add  "CR + LF" in between.

>  7.  SDP Signaling
>  
> !    A new feedback value "fss" needs to be defined for the Feedback Storm
> !    Suppression message to be used with Session Description Protocol
>     (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF)
>     [RFC4585].
>  
> --- 727,734 ----
>  
>  7.  SDP Signaling
>  
> !    We need to define a new feedback value "fss" for the Feedback Storm
> !    Suppression message which can be used by Session Description Protocol
>     (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF)
>     [RFC4585].

[Qin]: Good, Thank for your proposal.