Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02

[Magnus Westerlund <[e-mail]>]

On 2014-02-17 14:53, Eggert, Lars wrote:
> Hi,
> 
> we'd like to start the working group last call for 
> draft-ietf-rmcat-cc-requirements-02. Please send your feedback to
> the list.
> 

I have reviewed the draft and here are my feedback on the draft.

1. Abstract:

   This document is derived from draft-jesup-rtp-congestion-reqs
   [I-D.jesup-rtp-congestion-reqs].


I think this can be removed from the abstract. It doesn't appear
relevant at this stage to be in the abstract.

2. Section 1

   ... and since it's consumed in real
   time, data delivered late is useless.

I agree that is commonly useless, but not always. I don't know if we
want to be more precise here and write this as:

and since it's consumed in real
   time, data delivered late is commonly useless.

3. Section 1

   Given that this use case is the focus of this document, use cases
   involving noninteractive media such as YouTube-like video streaming,
   and use cases using multicast/broadcast-type technologies, are out of
   scope.

I wonder if it is appropriate to use the trademark "YouTube" in this
text. I would suggest to remove it.

4. Section 2, Req 1.D:

   Similarly periodic bursty flows such as DASH or proprietary

I would suggest adding a reference to DASH and possibly expand it.

5. Section 2, Req 1.D
            or
            may cause a shift in the location of the bottleneck fir the
            duration of the burst.

Spelling fir/for

5. Section 2, Req 3.A

        A.  If possible, it should also share information and adaptation
            with other non-RTP flows between the same endpoints, such as
            a WebRTC data channel

I would recommend a reference after "WebRTC data channel"

6. Section 2, Req 5.A
        A.  In order to react sufficiently quickly when using RTCP for a
            backchannel, an RTP profile such as AVPF/SAVPF that allows
            sufficiently frequent feedback [RFC4585] MUST be used.

The references and the RTP Profiles don't align well, I would suggest
that this is modified to:

        A.  In order to react sufficiently quickly when using RTCP for a
            backchannel, an RTP profile such as RTP/AVPF [RFC4585] or
            RTP/SAVPF [RFC5124] that allows
            sufficiently frequent feedback MUST be used.


7. Section 2, Req 5

A back channel requirement I don't know if it has been discussed is
the need for back channel congestion control.

8. Section 2, Req 6

        Flows managed by this algorithm and flows competed against at a
        bottleneck may have different DSCP markings depending on the
        type of traffic.  A particular bottleneck or section of the
        network path may or may not honor these markings.

A. This talks about DSCP only. What about flow based QoS? Is the not
included here as differnet network behaviors would require differnet
5-tuples. The RTP streams could still be under common application
control so I wonder if this is relevant?

B. I would ad a reference here to DSCP, and maybe you need to include
the word Diffserv here.

9. Section 2, Req 6.A

        A.  In WebRTC, a division of packets into 4 classes is
            envisioned in order of priority: faster-than-audio, audio,
            video, best-effort, and bulk-transfer.  Typically the flows
            managed by this algorithm would be audio or video in that
            heirarchy, and feedback flows would be faster-than-audio.

This doesn't match what is currently in
draft-dhesikan-tsvwg-rtcweb-qos-05. I wonder if this needs to be
either generalized or reference this document?

10. Section 2.

Another requirement that might be missing and is related to 6.A, but
not the same. It is the possibility to indicate the relative priority
between multiple streams in the same session context. This doesn't
require any QoS, just that the sending application indicates relative
priority and that affects how bit-rate gets distributed. Or has the
discussion been that it will be the higher layers that do this
re-distribution between streams for which one have indication if they
can increase or reduce the stream.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------