Subject: [AVTCORE] Proposed changes to draft-ietf-avtcore-ecn-for-rtp

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Mar 2011 16:32:45 +0100

Hi,

This email contains a number of suggested changes that are the result of
various comments on list and also off it. I appreciate rapid feedback as
the plan is to include it in an update submitted on Monday unless people
have suggestions for improvement or gripe with what is suggested.

Section 2:
I have received a comment that it not all clear what is meant with
Sender and Receiver. As this intended to be the RTP packet sender that
originates the data and the RTP packet receiver that sinks the media.
The complication are any media level middlebox such as a mixer or
translator that splits the ECN control loop. In these cases the mixer or
translator will also be senders and receivers due to that they sinks and
originates the RTP media packets. Thus I propose the following
definition to be added to section 2 after the abbreviation:

This document uses the terms sender and receiver according to the
following definition:

Sender: Sender of RTP packets carrying an encoded media stream. The
sender has the possibility to effect how this transmission is performed.
It is one end-point of the ECN control loop.

Receiver: A receiver of RTP packets with the intention to consume the
media stream in some form. It sends RTCP feedback on the received
stream. It is the other end-point of the ECN control loop.

Note: RTP mixers or translators that operate in such a manner that they
terminate or split the ECN control loop will take on the role of
receivers or senders. This is further discussed in Section 3.2.

Section 3.2:
I gotten a comment that it was unclear what was meant with "all known
receivers" in the following text:

>From Topo-Multicast:

      Accordingly, we allow ECN to be used
      by an RTP sender using multicast UDP provided the sender has
      verified that the paths to all its known receivers support ECN,
      and irrespective of whether the paths from other senders to their
      receivers support ECN.

The proposal to clarify this is to add after the above sentence:

"all its known receivers" are all the SSRCs that the RTP sender has
received RTP or RTCP from the last five reporting intervals, i.e. they
are not timed out.

Related to the above I have realized that we need to forbid the usage of
Group memebership sampling process as described by RFC2762. Thus I
suggest to add this to 3.2 as a second paragraph:

Due to the need for each RTP sender that intended to use ECN with RTP to
track all participants in the RTP session the sub-sampling of the group
membership as specified by "Sampling of the Group Membership in RTP"
[RFC2762] MUST NOT be used.

Section 6.1:
The ecn-capable-rtp attribute is defined as media level attribute.
However the previous text explicitly forbid it to be on session level.
But that blocks the default behavior specified in the SDP RFC 4566:

   The connection ("c=") and attribute ("a=") information in the
   session-level section applies to all the media of that session unless
   overridden by connection information or an attribute of the same name
   in the media description.  For instance, in the example below, each
   media behaves as if it were given a "recvonly" attribute.

OLD text:
 This is a
   media level attribute, which MUST NOT be used at the session level.

NEW text:
This is a media level attribute, thus it is normally included as part of
the media description, but if present at session level the same
configuration applies to all media descriptions.

Section 6.1:
Roni raised this:
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.

I propose that we change the text to:

In an RTP session using multicast all participants intending to send RTP
packets needs support setting ECT in the RTP packets, and all
participants receiving needs to have the capability to read ECN values
on incoming packets. Especially the later is important, otherwise no
sender in the multicast session will be able to enable ECN. If a session
is negotiated using offer/answer it is preferable that intended session
participant would be aware of the signalling attributes and if not
capable but ECN for RTP aware SHOULD refuse to join the session. For
intended session participants that are not aware of the ECN for RTP
signalling and simple ignore the signalling attribute the other party in
the offer/answer exchange SHOULD terminate the SIP dialog so that the
participant leaves the session.

Section 6.4:
I have received a comment that it was uncleared when the inclusion of
the ICE option for ECN checks was needed. The proposal is to mandate
both signal when including ICE initiation method.

NEW text:
Section 6.4
This ICE option SHALL be included when the ICE initiation method is
offered or declared in the SDP.

I have also fixed these typos, omissions:

Roni 2: Split the sentence and clarified it:
   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.  If
   timely feedback is not required it is still RECOMMENDED to used AVPF.

Roni 3: Added a=ice-options:rtp+ecn to both offer and answer

Roni 4A: Section 6.1: "However, using "mode=readonly" also in ASM
sessions is reasonable, unless all senders are required to attempt to
use ECN for the RTP packets they send, in which case the mode needs to
be set to "setread"."

Roni 4B: Section 7.4: The number of ECT packets received plus the number
of CE marked and lost packets should correspond to the number of sent
ECT marked packets unless there is duplication in the network.

Cheers

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: ken carlberg <[email-masked]>
Date: Thu, 10 Mar 2011 19:23:36 -0500

Hi,

Along these lines, we had an internal discussion concerning a suggested change in the first paragraph of Section 7.3.3.  The original text was the following:

7.3.3 Response to Congestion Notifications:

    When RTP packets are received with ECN-CE marks, the sender and/or
    receivers MUST react with congestion control as-if those packets had
    been lost.  Depending on the media format, type of session, and RTP
    topology used, there are several different types of congestion
    control that can be used.

the suggested new text is...

    The reception of RTP packets with ECN-CE marks in the IP header are a
    notification that congestion is being experience. The default reaction
    on the reception of these ECN-CE marked packets MUST be to provide the
    congestion control algorithm with notification and that it is treated as
    a packet loss would when it comes to indicating congestion.

    We note that there MAY be other reactions to ECN-CE specified in the
    future. Such an alternative reaction MUST be specified and analyzed to
    be safe for deployment under any restrictions specified. A potential
    example for an alternative reaction could be emergency communications
    (such as that generated by first responders, as opposed to the general
    public) in networks where the user has been authorized. A more detailed
    description of these other reactions, as well as the types of congestion
    control algorithms used by end-nodes, is outside of the scope of this
    document.

    Depending on the media format, type of session, and RTP
    topology used, there are several different types of congestion
    control that can be used.

The purpose of the suggested change is two fold.  One is to *explicitly* state that the congestion control algorithms are out of scope of the AVT draft.  The second suggested change was to continue reinforcing that congestion control algorithms MUST be the default action, but also recognize that there may be cases where other reactions may exist.  And taking this into account, we wanted to constrain and confine this possibility.

-ken

---

From: Roni Even <[email-masked]>
Date: Tue, 15 Mar 2011 15:28:05 +0200

Hi Magnus,
Sorry for not looking at it before the version came out. I have one comment.

> configuration applies to all media descriptions.

There is no such requirement in RFC 4566. See section 5.13 "Attributes are
the primary means for extending SDP.  Attributes may
   be defined to be used as "session-level" attributes, "media-level"
attributes, or both."
So it can be a media level attribute. If you want it to be a session level
attribute also than you will need to define it later in section 6.1 and in
the IANA registration section. My view is this is only a media level
attribute.

Roni Even

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Mar 2011 15:07:55 +0100

> the IANA registration section. My view is this is only a media level

Yes,

I have to agree after re-reading this. I can't understand how I came to
the conclusion that a media level only attribute can be at session level
also. I will ask my commentor about what supports his view.

Cheers

Magnus Westerlund