Re: [MMUSIC] Congestion control

Martin Thomson <martin.thomson@gmail.com> Mon, 10 June 2013 20:26 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5008721E8056 for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 13:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.375
X-Spam-Level:
X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 o9Q6Nt5sMhuW for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 13:26:35 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF6021E804B for <mmusic@ietf.org>; Mon, 10 Jun 2013 13:26:35 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id k10so3408957wiv.7 for <mmusic@ietf.org>; Mon, 10 Jun 2013 13:26:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=75dvZ0H0EOIPFUcyKX/crNDOHTq77i963+yMQDnkvn0=; b=pMExjudZ72klRbM6ymNvBxXLOc8k2SaCzwm7TziPtsmwxGN1z89li0vuURRqZQgIM1 nN73d6KQ6BpNC9tsNpkZdh5/GiSWazwA/YUrQx4uTH2u1EJlleSnkvULY0ZYiNUUx9V/ wwgrj1xBZLrFx1Z2iKo8u1a3RElH6+lKzJabWt5AR5s7zarRhSLt7zsvQXH7TPeSJljI DPSN9JlSCLUpIaWcMOUTivtPiXQhAnOGWxH9LI5ot5wbSucWN9+2hxaUOruWtzJL07/o m2823g6v/kHeEfdvsoOah6QCKSLEoj+bko8/Zl4a+W4QsEcl8QX+6Szq/Qzr3dvfXxEX u9LA==
MIME-Version: 1.0
X-Received: by 10.180.81.103 with SMTP id z7mr5556335wix.65.1370895984562; Mon, 10 Jun 2013 13:26:24 -0700 (PDT)
Received: by 10.194.60.46 with HTTP; Mon, 10 Jun 2013 13:26:24 -0700 (PDT)
In-Reply-To: <BLU169-W35E035EC4AC7AE5BBCCBBC93840@phx.gbl>
References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <BLU169-W609A2EAD331201B824EB6093980@phx.gbl> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> <BLU169-W35E035EC4AC7AE5BBCCBBC93840@phx.gbl>
Date: Mon, 10 Jun 2013 13:26:24 -0700
Message-ID: <CABkgnnVR9mJCA=Yn+ZcffBjPKnYNPJsspPpDDuXihdbuz6eAxw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Cullen Jennings <fluffy@iii.ca>
Subject: Re: [MMUSIC] Congestion control
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 20:26:36 -0000

On 10 June 2013 12:16, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> " No O/A is request to stop sending RTP packets on a given stream. "

With my Fluffy-filter on, I read that as saying: "No O/A is *required*
to stop sending RTP packets..."

> [BA]  So you're saying that you don't expect a=sendrecv/recvonly/sendonly to
> be used in Plan A to control streams described by individual m lines?    I
> had assumed that the O/A behavior described in RFC 3264 Sections 5.1 and 6.1
> would apply in Plan A.

I didn't infer anything like that.  I think that there is a distinct
difference between negotiating the possible existence of a stream and
requiring the existence of a stream.  When you use a=sendonly/etc...
you open the possibility of receiving the stream, which in most cases
will be fulfilled.  In a congestion scenario, the sender can (and
should) stop sending.

After all, the envelope established by SDP never excludes the
possibility that zero packets arrive.