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

Hi,Thomas:
Your clarification make sense to me. Thanks.

Regards!
-Qin
  ----- Original Message ----- 
  From: Belling, Thomas (NSN - DE/Munich) 
  To: ext Qin Wu ; Roni Even ; avt@ietf.org 
  Cc: Magnus Westerlund 
  Sent: Tuesday, October 11, 2011 11:14 PM
  Subject: RE: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

  Dear Qin, Magnus,

  Some replies to some of the earlier comments (I only briefly checked the rest).

  Thomas

  3. Section 3, 2nd paragraph

  "

     Counting vs Detecting Congestion:  TCP and the protocols derived from
     it are mainly designed to respond the same whether they experience
     a burst of congestion indications within one RTT or just one.

  "

  [Qin]: What's the difference between "one RTT" and "just one"?

  [Thomas] Intention seems rather to be "just one congestion indication".

  7. Section 3.2, 5th paragraph

  "

  The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate
  transmission of RTCP feedback, and has a minimal RTCP interval whose default value

   (5 seconds) is many times the normal RTT between sender and receiver.

  "

  [Qin]: What's the purpose of last sentence of this paragraph?
         Are you saying RFC3551 following Regular RTCP timing rule?
         or something else?

     Another question is according to RFC3551, the negotiation of
     parameters or membership control may be not support. in other wonder,
     there may be no way to negotiate ECN with RTP using SDP signaling,
     I am wondering can we say ECN with RTP can be used with the standard RTP/
     AVP profile [RFC3551]. 

  [Thomas] Negotiation is done with the 'ecn-capable-rtp' SDP attribute defined is this draft. Implantations not supporting ECN would ignore this, But this is independent of AVP or AVPF. 

  8. Section 3.3,3rd paragraph

  "

     For interoperability we mandate the implementation of the RTP/AVPF
     profile, with both RTCP extensions and the necessary signalling to
     support a common operations mode.  This specification recommends the
     use of RTP/AVPF in all cases as negotiation of the common
     interoperability point requires RTP/AVPF, mixed negotiation of RTP/
     AVP and RTP/AVPF depending on other SDP attributes in the same media
     block is difficult,

  "

  [Qin] How mixed negotiation is avoided when you don't put all the SDP attribute
   into the same media block? I don't really understand the rationale. Would you
  like to clarify a little bit?

  [Thomas] SDP capneg allows offering AVPF and AVP in the same media block, and also to relate SDP attributes to one of the transports only. Trouble is that this is not yet supported everywhere and has its problems with traversing intermediates not supporting it.

  [Qin]: It worth adding some text in the draft to make this clear.

  11. Section 4, 3rd paragraph

  "

     o  The sender may generate a (small) subset of its RTP data packets
        with the ECN field set to ECT(0) or ECT(1). 

  "

  [Qin] It is not clear to me where the ECN field is located.
  Is ECN field in the IP header or UDP header or RTP header?

  [Thomas] It is the IP header. Text could be modified accordingly, e.g.: 

      o  The sender may generate a (small) subset of its RTP data packets
        with the ECN IP header field set to ECT(0) or ECT(1). 

  13.Section 5.1,1st paragraph

  "

     This RTP/AVPF transport layer feedback format is intended for use in
     RTP/AVPF early or immediate feedback modes when information needs to
     urgently reach the sender.  Thus its main use is to report reception
     of an ECN-CE marked RTP packet so that the sender may perform
     congestion control, or to speed up the initiation procedures by
     rapidly reporting that the path can support ECN-marked traffic.

  "

  [Qin]: are you saying slow initiation procedure may result in network congestion?
  In my understanding, when ECN-CE marked packet is received, the only choice for sender
  is to do congestion control since you are not sure if initiation procedure lead to such
  congestion. If it is not intiation procedure that lead to congestion, you get risk to worse
  congestion condition? 

  [Thomas] I believe this does not only refer to initiation, but mainly to feedback if congestion is encountered after the ECN media flow has been established.

   [Qin]: I think your interpretation is correct. But I am not sure this is a issue, no?. The prolem is do we have way to identify which factor lead to the final congestion.

  slow initiation, timely feedback or intermediary cheating in between.

  Regards!

  -Qin

    ----- Original Message ----- 

    From: Roni Even 

    To: avt@ietf.org 

    Sent: Friday, September 30, 2011 8:29 PM

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

    Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. The WGLC will end on October 21, 2011

    Please review the draft and send comments to the list.

    Roni Even

----------------------------------------------------------------------------

    _______________________________________________
    Audio/Video Transport Core Maintenance
    avt@ietf.org
    https://www.ietf.org/mailman/listinfo/avt