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

"Bill Ver Steeg (versteb)" <versteb@cisco.com> Wed, 12 October 2011 12:57 UTC

Return-Path: <versteb@cisco.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3421F8C18 for <avt@ietfa.amsl.com>; Wed, 12 Oct 2011 05:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Level:
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m5l5MUwV9EH for <avt@ietfa.amsl.com>; Wed, 12 Oct 2011 05:57:19 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1381821F84A9 for <avt@ietf.org>; Wed, 12 Oct 2011 05:57:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=versteb@cisco.com; l=27752; q=dns/txt; s=iport; t=1318424239; x=1319633839; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=gb+7kVQpfjIU+aqEQ75OPQHHUR0ccDnWV99w3myFefU=; b=itK6UB92nwPtlEVuXCecI6qW42a3Sy7w3gw/AaSxxihcm3fm7/ARtST0 7zl2XblRyctaHKvcOg0sJ8syEbu/tJI/2w/8GcljMlHbVKG311pZkeoj9 v0SrWUjV6HzjcJyHrtEPRFVqftpnpA/MVRpwlUhgqSbC6OchygyhQk23z c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am8AAIONlU6tJV2d/2dsb2JhbABDgk2WQ4dtAYcxgQWBUwEBAQQSAQkRA1kCAQgRBAEBCwYQBwEGAUUJCAEBBAESCBqHZJsUAZ5ohndhBIdPMJEnjEE
X-IronPort-AV: E=Sophos; i="4.69,334,1315180800"; d="scan'208,217"; a="27831037"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 12 Oct 2011 12:57:18 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9CCvH20030136; Wed, 12 Oct 2011 12:57:17 GMT
Received: from xmb-rcd-312.cisco.com ([72.163.63.27]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 07:57:17 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC88DE.78CF251A"
Date: Wed, 12 Oct 2011 07:57:16 -0500
Message-ID: <117602CF2B17DB4F9001427FA6D9053996F6FF@XMB-RCD-312.cisco.com>
In-Reply-To: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
Thread-Index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQIsm8UQ
References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com>
From: "Bill Ver Steeg (versteb)" <versteb@cisco.com>
To: "Roni Even" <Even.roni@huawei.com>, <avt@ietf.org>, "Magnus Westerlund" <magnus.westerlund@ericsson.com>
X-OriginalArrivalTime: 12 Oct 2011 12:57:17.0919 (UTC) FILETIME=[78E36EF0:01CC88DE]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2011 12:57:24 -0000

Magnus, Roni - 

 

Congestion control is an important area, and I support this document moving forward  after we take care of some issues. 

 

In this note, I list a few important points, followed by some less important comments.

 

Important points -

 

 

For the multicast case, we need to make it clear that feedback goes to the feedback target, which may be a different device than the source. This document consistently says "feedback goes to the source", which is misleading. See the detailed comments below for the places in which I found it to be most concerning. When viewed in the context of feedback going to a discrete feedback target at the network egress edge (like typical IPTV deployments), it makes sense for the feedback target to use these reports as diagnostic in nature. Perhaps the network has changed topology and caused a bottleneck link to appear, and the feedback is triggering action in the network to fix the congestion in a systematic manner. It is highly unlikely that RTCP feedback will be able to change the rate of a flow in such a system. It is more likely that the system would take other actions, but that is probably beyond the scope of this document.

 

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 - particularly in the IPTV multicast case. If an operator needs to dual carry hundreds of video channels (one ECN marked and one not ECN marked), he will simply not implement ECN. I need to think about this a bit more and see if there is a way to make this work. My first instinct was to add a field/bit pattern to the RTCP feedback that says " I joined the ECN enabled flow, but can't actually read the ECT/ECN markings". However, let's think about naïve receivers that do not understand the ECN SDP. They will ignore that SDP line, and join the flow. They will provide their normal feedback, without the ECT/ECN portions. How is this different from a receiver that knows about ECN, but is unable to actually read the ECN bits? Maybe we just treat it like a legacy receiver that does not know about the ECN SDP....... So, we need to think about three receiver populations - fully ECN capable (as currently described in this document), ECN aware in the application but unable to read ECN bits (either acts like a legacy receiver or sends a special RTCP feedback message), ECN unaware (ignores the SDP). I have thought about this in the context of the declarative SDP case using leap of faith, but need to think more about the offer/answer case and the STUN case. We need a way to have each type of receiver unambiguously join the same multicast flow. This would allow an operator to incrementally deploy ECN on multicast flows. If we do not fix this, the operator will be gated on the very last device in his deployment.

 

 

It would be nice to have the RTCWEB folks take a courtesy look, as they are envisioning some very interesting use cases. I do not think that this presents any specific challenges, but it would be good to have those eyeballs. I see that at least a few of them have provided comments.........

 

 

 

A few minor points and a bit more specificity on the major points------------

 

There is a delicate balancing act between providing timely congestion notifications to the sender and sending feedback packets into a congested network. It is not clear that the this balancing act is discussed in enough detail in the document. An inexperienced implementer may "do the wrong thing" and send packets to freely, thus making the congestion worse. Perhaps a short paragraph in the introduction would make this clear? Perhaps a paragraph at the end of Page 11? Also in section 7.3.2, as congestion is not highly featured in RFC4585 or RFC3550. Congestion is mentioned in 7.3.2, as is feedback implosion, but there is no warning about how they can interact.

 

 

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.

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.

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. 

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.

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.

6--- Page 15, and then sprinkled throughout the document

Is feedback send to the sender, or to the feedback target?

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.

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".

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.

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

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.

 

 

BVS

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Friday, September 30, 2011 8:29 AM
To: avt@ietf.org
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