Subject: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00

From: Roni Even <[email-masked]>
Date: Tue, 15 Feb 2011 22:46:07 +0200

Hi,

1.       In section 6.1 there are these two sentences: "If the participant
lack the functionality they SHALL refuse the media streams using multicast."
and " Participants MUST NOT join such a session unless they have the
capability to receive ECN-marked UDP packets," I am not sure how that works
for participants who do not understand the ecn-capable-rtp attribute. I
think that they will ignore the attribute and join the session and will not
use ECN.

2.       In section 6.1 "Thus, the use of the Extended RTP Profile for
RTCP-Based Feedback(RTP/AVPF) [RFC4585] or other profile that inherits
AVPF's signalling rules, MUST be signalled unless timely feedback is not
required in case it is RECOMMENDED to be used. " I am not sire what is meant
by the last part of the sentence "in case .".

3.       In the example is section 12.1 with ICE I did not see
"a=ice-options: rtp+ecn" in the offer, is this required?

4.       Some typos in 6.1 " unless all senders are required to attempt to
use ECN for there outgoing sessions" should be "their" and in 7.4 "ECT
marked packets unless their is duplication in the network" should be
"there"

Roni Even

 

  _____

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Feb 2011 10:30:56 +0100

Thanks, for the review Roni.

Roni Even skrev 2011-02-15 21:46:
> Hi,
> 
> 1.       In section 6.1 there are these two sentences: "If the
> participant lack the functionality they SHALL refuse the media streams
> using multicast." and " Participants MUST NOT join such a session unless
> they have the capability to receive ECN-marked UDP packets," I am not
> sure h ow that o do not understand the ecn-capable-rtp attribute. I
> think that they will ignore the attribute and join the session and will
> not use ECN.

Lets look at each statement separtely:

   If an RTP session using multicast is negotiated using offer/answer
   all participants intending to send RTP packets SHALL support setting
   of ECN packet, and all participants receiving SHALL have the
   capability to read ECN values on incoming packets.  If the
   participant lack the functionality they SHALL refuse the media
   streams using multicast.

This clearly can be improved. But as it is offer/answer we should make
it clear that the other part in a session requiring multicast and ECN
shall ensure that the joining participant is capable. Thus using SIP
methods for terminating the dialog and the other participants attempt to
take part in the session. Does this make more sense?

   When SDP is used in a declarative manner, for example in a multicast
   session using the Session Announcement Protocol (SAP, [RFC2974]),
   negotiation of session description parameters is not possible.  The
   "a=ecn-capable-rtp" attribute MAY be added to the session description
   to indicate that the sender will use ECN in the RTP session.  The
   attribute MUST include a single method of initiation.  Participants
   MUST NOT join such a session unless they have the capability to
   receive ECN-marked UDP packets, implement the method of initiation,
   and can generate RTCP ECN feedback (note that having the capability
   to use ECN doesn't necessarily imply that the underlying network path
   between sender and receiver supports ECN).  The mode parameter MAY be
   included also in declarative usage, to indicate the minimal
   capability is required by the consumer of the SDP.  So for example in
   a SSM session the participants configured with a particular SDP will
   all be in a media receive only mode, thus mode=readonly will work as
   the capability of reporting on the ECN markings in the received is
   what is required.  However, using "mode=readonly" also in ASM
   sessions is reasonable, unless all senders are required to attempt to
   use ECN for there outgoing sessions, in which case the mode needs to
   be set to "setread".

So this is declartive and multicast. I agree that it is a difficult case
to ensure that no implementations doesn't join. However, for declarative
multicast sessions, you frankly need to understand the session you are
joining in. I know that our specs could be clearer on this, but if you
join a multicast session and don't understand all the parameters you
will be in trouble.

Thus, it is possible that some applications implement detection of
attributes, but not the corresponding functionalities simply to ensure
that they do not join the session unnecessary. Thus, I think the
statement is necessary, but I agree not 100% ensuring that this will not
happen. I can clarify this.

> required in case it is RECOMMENDED to be used." I am not sir e what i of
> the sentence "in case …".

This sentence should be broken into two. IT tries to say even if not
stricitly required, is is still recommended to use AVPF. Will reformulate.

> "a=ice-options: rtp+ecn" in the offer, is this required?

That should be included, forgotten in the example. It should be
incldued, but is in fact not strictly needed due to the ICE based
initiation method negotation in the ecn-capable-rtp SDP attribute.

> 
> 4.nbsp;  Some typos in 6.1 " unless all senders are required to attempt
> to  use ECN for there outgoing sessions" should be "their" and in 7.4
> "ECT marked packets unless their is duplication in the network" should
> be  "there"

Thanks, will fix.

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Fri, 18 Feb 2011 14:56:35 +0200

Hi Magnus,

Inline

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, February 18, 2011 11:31 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00
> 
> streams

My concern in offer answer is that a legacy system that will receive an
offer with ecn attribute may accept the stream and remove the attribute in
the answer without violating offer/answer. I think that it will be up to the
offrer to terminate the session when noticing the lack of the ecn attribute
in the answer.

Regards
Roni Even

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Feb 2011 11:29:13 +0100

> offrer to terminate the session when noticing the lack of the ecn attribute

Yes, that is rightly a concern. I will attempt to clarify the need for
the capable end-point to notice that and then either accept that ECN
will fail, or terminate the dialog with that participant.

Cheers

Magnus Westerlund