Subject: Re: [AVT] comments about draft-westerlund-avt-ecn-for-rtp-00

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 18 Sep 2009 08:35:13 +0200

Hi

For the record 
The 3GPP SA-4 work on ECN based adaptation aims at receiver driven
adaptation for VoIP. The main reason is that it fits well with the
already existing packet loss based adaptation in TS 26.114. 
Video is not specified in too much detail and in this case it is
possible that sender based adaptation is better but this is T.B.D

/Ingemar

> 
> Message: 1
> Date: Thu, 17 Sep 2009 14:06:29 +0200
> From: Magnus Westerlund <[email-masked]>
> Subject: Re: [AVT] comments about draft-westerlund-avt-ecn-for-rtp-00
> To: Roni Even <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi Roni
> 
> Roni Even skrev:
> > Hi,
> > 
> > I did a quick review of the draft.
> > 
> >  
> > 
> > I noticed that you have the support for AVPF as optional 
> and even have 
> > in section 4.2.1 the following text
> > 
> > " RTP/AVPF has not been negotiated, then the RTCP ECN 
> feedback should be
> > sent in a compound RTCP packet     along with the regular 
> RTCP reports."
> > 
> > The RTCP ECN message is defined as an RFC 4585  feedback 
> message and 
> > as such can only be sent under AVPF/SAVPF profile and not AVP
> > 
> 
> I think we are going to require (S)AVPF support because of 
> the need for quick feedback to received CE marked packets. 
> But, we will fix this to be consistent.
> 
> >  
> > 
> > I section 4.1.2 you use the ICE option at the session level 
> yet when 
> > using SDP you have the ECN capability as a media level 
> which direction 
> > do you intend to use.
> > 
> 
> Hmm, yes another consistency issue that we will look into.
> 
> >  
> > 
> > In section 4.3.3 on receiver driven congestion control you 
> can use the 
> > flow control rtcp feedback message (from ccm) to control 
> the video rate.
> > 
> >  
> 
> Yes, that is a possibility on how to implement it for 
> unicast. But, we don't intended to define a complete 
> congestion control system with response to markings. This 
> draft is focused on providing ECN information to any 
> adaptation and congestion control mechanism.
> 
> cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 17 Sep 2009 14:13:51 +0200
> From: Magnus Westerlund <[email-masked]>
> Subject: Re: [AVT] Two questions on "ECN for RTP"
> To: Colin Perkins <[email-masked]>
> Cc: VAN CAENEGEM Tom <[email-masked]>,
> 	[email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Colin Perkins skrev:
> > Tom,
> > 
> > You might have a different congestion response, depending on which 
> > packets were lost/marked. For example, if tightly spaced 
> packets are 
> > marked, this might be considered a single congestion event, 
> where as 
> > the same fraction of packets being marked over a longer 
> period of time 
> > might be treated as several loss events. We want to allow 
> flexibility 
> > in the congestion response, since it's not clear what's the 
> correct response.
> 
> Also to be able to check if the receivers claim ECN nonce 
> value is the right value then you need to tell the sender 
> which packets you have not included in the ECN nonce. The 
> only packets valid to exclude are either lost or reported as 
> CE marked.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 17 Sep 2009 09:45:01 -0700 (PDT)
> From: [email-masked]
> Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
> To: [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 17 Sep 2009 12:56:30 -0400
> From: Ye-Kui Wang <[email-masked]>
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> 
>  
> Changes compared to -18 are list below, among other minor 
> editorial changes:
>  
> - alignment of recent changes to the RFC 3984bis draft
> - update of some references for which the RFCs are now available
> - SDP examples are now in line with RFC5583
> - change of Stephan's affiliation and address
> - change of Thomas' email address 
> 
> I hope Chairs could issue a second WGLC for this draft.
> 
> BR,YK
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > [email-masked]
> > Sent: Thursday, September 17, 2009 12:45 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Audio/Video Transport 
> Working Group 
> > of the IETF.
> > 
> > 
> > 	Title           : RTP Payload Format for SVC Video
> > 	Author(s)       : S. Wenger, et al.
> > 	Filename        : draft-ietf-avt-rtp-svc-19.txt
> > 	Pages           : 103
> > 	Date            : 2009-09-17
> > 
> > This memo describes an RTP payload format for Scalable Video Coding
> > (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is 
> > technically identical to Amendment 3 of ISO/IEC 
> International Standard 
> > 14496-10.  The RTP payload format allows for packetization 
> of one or 
> > more Network Abstraction Layer (NAL) units in each RTP 
> packet payload, 
> > as well as fragmentation of a NAL unit in multiple RTP packets.
> > Furthermore, it supports transmission of an SVC stream over 
> a single 
> > as well as multiple RTP sessions.  The payload format defines a new 
> > media subtype name "H264-SVC", but is still backwards compatible to 
> > [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when 
> encapsulated 
> > in its own RTP stream, must use the H.264 media subtype 
> name ("H264") 
> > and the packetization method specified in [I- 
> > D.ietf-avt-rtp-rfc3984bis].  The payload format has wide 
> applicability 
> > in videoconferencing, Internet video streaming, and high bit-rate 
> > entertainment-quality video, among others.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-19.txt
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 65, Issue 31
> ***********************************
>