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

"Dan Wing" <dwing@cisco.com> Thu, 13 October 2011 17:35 UTC

Return-Path: <dwing@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 05A8F21F88B7 for <avt@ietfa.amsl.com>; Thu, 13 Oct 2011 10:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.221
X-Spam-Level:
X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 anQ7xuKQ+0NM for <avt@ietfa.amsl.com>; Thu, 13 Oct 2011 10:35:07 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6231421F8678 for <avt@ietf.org>; Thu, 13 Oct 2011 10:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2432; q=dns/txt; s=iport; t=1318527307; x=1319736907; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=xmkgnfw0xlVhthCskDjzXf9cYJOpN047w4ZJ9V9xhIE=; b=PEWi9fUuYVGKc03ut+f000t3artv1bu24w5galmEk7zqe+/DcndmlCS6 N8vbNi8xOrQruNhVqbItGFoUFk0dPF5TLrVDQNSjcayqRp2xxnHPpV9gD KH+chWlKv2UIWMiLavq3/U06KbMtRJFIdX7m9UIaG2XHzjFk5Jz3HGpKZ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqEAAIYgl06rRDoG/2dsb2JhbABDmTSBbI05gQWBUwEBAQQICgEVAhBLAQMCCQ8CBAEBKAcZIwoJCAEBBAESCxeHZJlFAZ4wh20EiAGdbA
X-IronPort-AV: E=Sophos;i="4.69,341,1315180800"; d="scan'208";a="7706926"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 13 Oct 2011 17:35:06 +0000
Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9DHZ5VC003960; Thu, 13 Oct 2011 17:35:06 GMT
From: "Dan Wing" <dwing@cisco.com>
To: <avt@ietf.org>, <draft-ietf-avtcore-ecn-for-rtp@tools.ietf.org>
References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com>
In-Reply-To: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com>
Date: Thu, 13 Oct 2011 10:35:05 -0700
Message-ID: <008b01cc89ce$724dee80$56e9cb80$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQKYIHzQ
Content-Language: en-us
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: Thu, 13 Oct 2011 17:35:08 -0000

Two comments:

1. The section
http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2
does not seem to discuss what happens if the ECN-marked ICE messages are
discarded (e.g., by an aggressive firewall).  This seems to be an oversight.
For this to work better, I suggest sending two STUN messages, back to back:
one with ECN set and the other with ECN clear.  If the response to the
ECN-set message isn't received within, say, 20% of the time for the
ECN-cleared message, assume ECN-marked messages are being dropped/filtered.
Note one of the non-ECN'd messages can be the normal ICE exchange, so if
you're already doing ICE I am not proposing any additional messages on the
wire.

I expect the other packet probes (RTP/RTCP probes) may need similar
consideration / adjustment.


2. The section
http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2
can be summarized as:

  a. do normal ICE
  b. use ICE messages to do an ECN validation
  c. if (b) showed ECN worked, start sending RTP with ECN.  
  d. if (b) showed ECN failed, start sending RTP without ECN.

Step (b-d) adds additional call setup time, which is undesirable.

Instead, I would prefer changing two aspects:  (1) not relying or caring
about an initial ICE transaction (which means we can have both endpoints
merely do ICE-Lite, if they wish -- we only need to know they will respond
to ICE, really -- we don't need all of the other ICE overhead to use ICE to
test the path is ECN capable), and (2) sending non-ECN'd RTP without
waiting.  That can be summarized as:

  a. immediately start sending RTP without ECN
  b. use ICE messages to do ECN validation
  c. if (b) showed ECN worked, start sending RTP with ECN.  
  d. if (b) showed ECN failed, start sending RTP without ECN.

-d


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