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.
- [MMUSIC] MMUSIC Working Group Virtual Interim Mee… Flemming Andreasen
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Martin Thomson
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Mary Barnes
- [MMUSIC] MMUSIC Working Group Virtual Interim Mee… IESG Secretary
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Flemming Andreasen
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Martin Thomson
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Cullen Jennings
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Emil Ivov
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Emil Ivov
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Mary Barnes
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Flemming Andreasen
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Bernard Aboba
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Flemming Andreasen
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Emil Ivov
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Paul Kyzivat
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Emil Ivov
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Flemming Andreasen
- [MMUSIC] Congestion controll Cullen Jennings
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Emil Ivov
- Re: [MMUSIC] Congestion controll Bernard Aboba
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Kevin Dempsey
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Flemming Andreasen
- Re: [MMUSIC] Congestion controll Cullen Jennings
- Re: [MMUSIC] Congestion controll Martin Thomson
- Re: [MMUSIC] Congestion controll Emil Ivov
- Re: [MMUSIC] Congestion controll Martin Thomson
- Re: [MMUSIC] Congestion controll Emil Ivov
- Re: [MMUSIC] Congestion control Bernard Aboba
- Re: [MMUSIC] Congestion controll Martin Thomson
- Re: [MMUSIC] Congestion control Martin Thomson
- Re: [MMUSIC] Congestion control Cullen Jennings
- Re: [MMUSIC] Congestion control Cullen Jennings
- Re: [MMUSIC] Congestion control Bernard Aboba
- Re: [MMUSIC] Congestion control Martin Thomson
- [MMUSIC] WebEx info for MMUSIC Working Group Virt… Flemming Andreasen
- Re: [MMUSIC] MMUSIC Working Group Virtual Interim… Flemming Andreasen