Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

[Magnus Westerlund <[e-mail]>]

Hi,

some more in detail comments.

I propose that the SSM usage is clarified in section 3.3 by adding the
following text.

      SSM groups that uses unicast RTCP feedback [RFC5760] do need a few
      extra considerations.  This topology can have multiple media
      senders that provides traffic to the distribution source (DS) and
      are separated from the DS.  There can also be multiple feedback
      targets.  The requirement for using ECN for RTP in this topology
      is that the media sender must be provided the feedback from the
      receivers, it may be in aggregated form  from the feedback
      targets.  We will not mention this SSM use case in the below text
      specifically, but when actions are required by the media source,
      they do apply also to case of SSM where the RTCP feedback goes to
      the Feedback Target.

But, I guess that you might find this insufficient. But, I don't see how
we can take care of all implications of large scale multicast usage.

Maybe what we should add is:

"This specification do support multicast, but has primarily considered
smaller multicast groups and is not optimized for larger groups and
their needs."



On 2011-10-12 14:57, Bill Ver Steeg (versteb) wrote:
> 
> 1---- Page 7
> 
>    ECN support is more important for RTP sessions than, for instance, is
> 
>    the case for TCP.
> 
>  
> 
> This is a quite bold statement. I suspect that the following sentence is
> closer to the truth, but it is truly a minor point.
> 
> ECN support is as important for RTP sessions as it is  for TCP.

I still believe based on the motivation provided below this sentence
that the original one is true. Yes, I can see if "delay" is your main
performance factor, then TCP might be similarly benefited by ECN.

> 
> 2--- Page 13
> 
> ---- begin rant ---- I am always troubled by language discussing 
> signaling protocols and discovery in RTP documents. We all know that
> declarative SDP is often used to configure endpoints. There is probably
> nothing that needs to be changed in this section, but I am noting that
> “declarative SDP” is not equal to a signaling protocol used for
> discovery. --- end rant ---
> 
> I need to think about the typical Service Provider use case- delivery of
> IPTV to a very large population of receivers. The system is setup with
> declarative SDP. Is the sender REALLY going to probe all of the
> receivers and stop marking packets with ECN if a few receivers don’t
> respond? If you have a population of several million receivers at the
> end of DSL lines, what are the odds of none of them being offline for a
> few minutes? I would venture a guess that it is pretty small. In this
> case, the “leap of faith” is probably what the network operator will
> do……. So, I do not think I have a problem with this section, other than
> the rant.

I assume the rant is over this following sentence:

   Before an RTP session can be created, a signalling protocol is used
   to discover the other participants and negotiate or configure session
   parameters (see Section 7.1).

Is this better?

   Before an RTP session can be created, a signalling protocol is used
   to negotiate or at least configure session parameters (see
   Section 7.1).  In some topologies the signalling protocol can also be
   used to discover the other participants.

> 
> 3--- Page 13
> 
> Considering again the case of the large Service Provider. The feedback
> target for the flow is usually a repair device rather than the sender.
> It is not clear from the text if the RTCP is going to the repair device
> or the sender.

I assume this is sentence that triggers your comment:

 Upon reception of this feedback from each
      receiver it knows of, the sender can consider ECN functional for
      its traffic.

Is that more acceptable in the light of the section 3.3 addition making
clear the requirement that in case of SSM the media sender will get a
aggregated information.

> 
> 4--- Page 14
> 
> Is feedback send to the sender, or to the feedback target? Hopefully it
> goes to the feedback target, or else you are going to have one hell of a
> feedback storm in certain deployments.

Well, if you have an SSM with feedback targets then it goes to the
feedback targets. As stated in 3.3 addition I see an feedback target
aggregating the information to the media sender.

> 
> 5--- Page 15
> 
> I need to think about the case in which a large IPTV deployment is using
> these methods, then one of the subscribers deploys a wireless gateway
> that mangles ECT/ECN packets. It is not clear that the sender SHOULD
> stop sending ECT/ECN marked packets. In a perfect world, the subscriber
> would have a way to know that the problem is in the gateway….. I am not
> sure we can fix this problem in the scope of this document, though.

No, I don't see how we really can deal with it. As I said before I think
we likley need that disclaimer for larger multicast groups.

> 
> 6--- Page 15, and then sprinkled throughout the document
> 
> Is feedback send to the sender, or to the feedback target?

It is sent to where ever you send your RTCP packets, but the feedback is
addressed to the SSRC that you report on.

> 
> 7--- My SDP skills are suspect. It looked OK on a quick read, but
> hopefully somebody is looking at this in detail. I am not sure I like
> the setread/setonly/readonly semantics, but I do not have a
> counter-proposal.

Noted, input by SDP gurus desired.

> 
> 8--- Page 23 and 24
> 
> If a host is unable to read the ECN bits, it can’t join an ECN-enabled
> flow? This seems to be quite onerous, and will likely slow down the
> adoption of ECN for RTP. This is particularly true of the “large IPTV
> deployment” that wants to send multicast flows to STB, PC, Xbox, tablet,
> etc. If there are millions of receivers, that means that there are
> dozens/hundreds/thousands of device types. If the operator is gated on
> having ECN support on all of the devices, this will never get deployed.
> Perhaps we can change the feedback report to say “ I joined the stream,
> but can’t actually read the ECN bits, so do not count me in your ECN
> algorithm”.

Yes, but as stated in previous email I don't see how we can allow
someone who don't react, nor report to the congestion signals to join
the group.

> 
> 9--- section 7.2.1
> 
> If the feedback goes to a discrete feedback target, the system will have
> to correlate the responses and send a summary to the original sender.

Yes, I think this would be fixed by 3.3 addition.

> 
> 10 --- page 28
> 
> change
> 
> For video formats, packets containing P- or B-frames, rather than I-frames,
> 
>       would be an appropriate choice
> 
> to
> 
> For video formats, packets containing NULLS, P-frames or B-frames
> (rather than I-frames),
> 
>       would be an appropriate choice

I have done the change, but isn't this a US vs UK english thing?

> 
> 11--- page 29
> 
> For streams with millions of receivers (think IPTV and the World Cup
> Final), the group will never be stable for three RTCP reporting
> intervals. Perhaps a group associated with a given feedback target would
> be stable for this long, but even that is marginal.

I agree this is an issue. But I would group this with the large
multicast group issues that we have identified as being problematic.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------