Re: [MMUSIC] Congestion controll

Martin Thomson <martin.thomson@gmail.com> Mon, 10 June 2013 20:17 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 C41F021F9A13 for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 13:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 es5tmjVHpm5N for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 13:17:00 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B432121F9A12 for <mmusic@ietf.org>; Mon, 10 Jun 2013 13:16:59 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id a12so3389669wgh.4 for <mmusic@ietf.org>; Mon, 10 Jun 2013 13:16:58 -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=2DPlzaoIQaijfo18IseXS24PsZ3m4yXY5Lbd2tdRKrg=; b=b8Ecw+EB9LpfcL4pjfDo2U8dtiP37gUqX9Q5r/yXCwstyawi8MyMX3QW53zNv/L3Iy U9GsG6yeXfvsgTp6vKE/Ge0oXnEWnvCVO23C1onI4y/RSHcgA5yBcxaQBjEpr0sUaGth JSS+fJSt4g1h5Yi/81IlvCoPVyl4lZk9XMLlFufsrcJ8okoZ4kdZGCpWJnt4g0DMX+Nj fHwhFYWSCuEM56bjNB5Vzq8cNXt5C+0OpuIpq4Eug6Dk8HXDm3sFfoLe1zsum7syaRuL Ukedblojk7DpTHti4iS+GXjt1tjX58Y7JeJjqb++iwlSk6L71AQJiwh3+uWlW+uKMxo+ AXkw==
MIME-Version: 1.0
X-Received: by 10.180.39.236 with SMTP id s12mr1513306wik.14.1370895418922; Mon, 10 Jun 2013 13:16:58 -0700 (PDT)
Received: by 10.194.60.46 with HTTP; Mon, 10 Jun 2013 13:16:58 -0700 (PDT)
In-Reply-To: <CAPvvaaLufqpkaBM=SBhSw0jHdswVMATLk3VLMgSgHRXm9-GBRA@mail.gmail.com>
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> <CABkgnnUFbc0+A=-rFZRSPN+maXCDHv7QnOOuf4N+wFOc_u7h4g@mail.gmail.com> <51B6086E.5020802@jitsi.org> <CABkgnnWJrhCPpV2rfwkb5cDhPXC=ACoN2602sSW_sA9HXicKXg@mail.gmail.com> <CAPvvaaLufqpkaBM=SBhSw0jHdswVMATLk3VLMgSgHRXm9-GBRA@mail.gmail.com>
Date: Mon, 10 Jun 2013 13:16:58 -0700
Message-ID: <CABkgnnXnegiGoSAC1vDkbeVeR1eBrMJVM9ECjDumzdOpA5YOBw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: text/plain; charset=UTF-8
Cc: Flemming Andreasen <fandreas@cisco.com>, Ari Keranen <ari.keranen@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, Cullen Jennings <fluffy@iii.ca>
Subject: Re: [MMUSIC] Congestion controll
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:17:00 -0000

On 10 June 2013 11:12, Emil Ivov <emcho@jitsi.org> wrote:
> On Mon, Jun 10, 2013 at 7:19 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> Well then you've assumed something about Plan A/B that is incorrect.
>
> I am not following. Could you please point me to the specific
> assumption that you have in mind?

Um, your argument in this thread?

Also, Section 1:

   Finally, both Plan A and Plan B, also create expectations that fine
   grained control of FEC, layering and RTX flows will always be
   implemented through Offer/Answer, which would not necessarily the
   best way to handle this in congested situations.

That draws a line from control of FEC/layering, etc... with O/A to
congestion control.

>> Neither plan constrains usage in a way that would prevent senders from
>> responding to congestion signals. The fine-grained control that you
>> report as being problematic doesn't prevent senders from sending fewer
>> bits.
>
> No, not explicitly at least. However, the more senders respond to
> congestion signals the more they end up with inconsistencies between
> what's been requested from the remote SDP, what the local application
> would like to happen and what is actually happening. Such situations
> would be much harder to control when all you've got is the remote SDP.

I really don't think that is a valid argument.  As you observe
congestion, you alter what you send.  Preferably toward sending fewer
bits.  That might result in sending nothing at all for some streams
(which would be one value for "fewer bits").

SDP describes the envelope within which you operate, that's all.
Neither plan A nor plan B expressly state that SDP is expressing
constraints on how a sender might alter their behavior in response to
congestion signals.

Think of it this way: I will simulate 100% packet loss to satisfy a
need to alleviate congestion, if there are no other options available.
 After all, that's what happens if I let congestion worsen.  There is
nothing an API, or SDP, can do to stop me from doing that.