Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 26 April 2016 22:28 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 0E88412D0FA; Tue, 26 Apr 2016 15:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjBra8oNomjY; Tue, 26 Apr 2016 15:28:06 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B7612D0B0; Tue, 26 Apr 2016 15:28:06 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id o66so42613274ywc.3; Tue, 26 Apr 2016 15:28:06 -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; bh=MzE/sAKHtsmmJH1FN0df65zarXuttsPRxgVGU0ie3/A=; b=QwR0wN9jO2uB/PlQZcI1nYD8waWhJctgSyCQ/BGoFQrju/OGPZ66EiJycctYAM6C8K fH2SdcZsynKL8DzhZq6RVbF3J5PBcVIcE51SZDtvlcFJePdjrv1jjkSxt4Fsyv0xgO/d n08htTfTj5lKCLRRpsEKAFGln26w9KKmBethzCoTp5rTqwwwxmogjEZnUNmvd7hA1ZUI 71OaqHT9rughCuxWSU0vXps/nwU0dhp0ycBOYD8UMUVv+dkiMxPmy+hDyp6WB4pIAc4q wxmsiZkWXZquOADptYvmP52YjLyjg5xzQ5TWXqD3+99Pe6an0L51Ogc++FypLX9c8QoI pbkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MzE/sAKHtsmmJH1FN0df65zarXuttsPRxgVGU0ie3/A=; b=FsWyfIls1xQfi0DeV3PNsUNacg3Hwzo5YqKwEFhESmAYv7dZ/Wf4otDwY9oR3WH+JX ldj/R6B+ENcWGKlbqmhnlKz8p9U31OvkBMDtyJvMizmoMvine8NIXbaHCZ45GanODALr EQ//b0J5zln8kGnJKhNclDpvgK1ZLlzDnC1bBvwEid3JmzL/Ov/qWKek1cU0pY/TXgQq Arf7ixs/4fW65RPD4p0/1N2uh5jNl/iPl01OP5Vh4MZlR81Wu1Y6Z21c8bS+e12GaKxI 2vq5SWXdILgaVg5JlHi307ZZ6nuFIsvISenclQx8m0y+WjApKxu8b4pH6ihAFaez0n9Q zr7A==
X-Gm-Message-State: AOPr4FVF6oONudRZCaVFK+xVTsugjEz2fsB8ZMtTeW04Mr7uZW40fkTF3CZQhJmiQ2IL0QYWHZMcFBRUeKmwXQ==
MIME-Version: 1.0
X-Received: by 10.13.196.132 with SMTP id g126mr3255017ywd.258.1461709685916; Tue, 26 Apr 2016 15:28:05 -0700 (PDT)
Received: by 10.37.224.212 with HTTP; Tue, 26 Apr 2016 15:28:05 -0700 (PDT)
In-Reply-To: <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org>
References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> <CAKKJt-e5xQjkHQ8AWpp6N1eUM_KvFNuJ_CyNE7QdQyYjzAPHUw@mail.gmail.com> <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org>
Date: Tue, 26 Apr 2016 17:28:05 -0500
Message-ID: <CAKKJt-c01K6W=HCBrs5wHynfMZLh0P5AEZS4aO8j7-dTbGzDzw@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: Colin Perkins <csp@csperkins.org>
Content-Type: multipart/alternative; boundary=001a114d7ed4980c6305316aceb5
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/1-Do2aE3m9fcSat6GMHHMH7ePVg>
Cc: avtcore-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG <iesg@ietf.org>, avt@ietf.org
Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 26 Apr 2016 22:28:09 -0000

Hi, Colin,

On Tue, Apr 26, 2016 at 5:13 PM, Colin Perkins <csp@csperkins.org> wrote:

> Hi,
>
> > On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
> >
> > Hi, Colin,
> >
> > On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins <csp@csperkins.org>
> wrote:
> >
> >> Spencer,
> >>
> >>> On 20 Apr 2016, at 02:20, Spencer Dawkins <spencer.dawkins@huawei.com>
> wrote:
> >>>
> >>> Spencer Dawkins has entered the following ballot position for
> >>> draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss
> >>>
> >>> When responding, please keep the subject line intact and reply to all
> >>> email addresses included in the To and CC lines. (Feel free to cut this
> >>> introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>> for more information about IESG DISCUSS and COMMENT positions.
> >>>
> >>>
> >>> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/
> >>>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>> I really like this specification, and have two questions I'd like to
> >>> understand before balloting YES ...
> >>>
> >>> I'm looking at this text:
> >>>
> >>> 4.5.  Ceasing Transmission
> >>>
> >>>  What it means to cease transmission depends on the application.  The
> >>>  intention is that the application will stop sending RTP data packets
> >>>  to a particular destination 3-tuple (transport protocol, destination
> >>>  port, IP address), until the user makes an explicit attempt to
> >>>  restart the call.  It is important that a human user is involved in
> >>>  the decision to try to restart the call, since that user will
> >>>  eventually give up if the calls repeatedly trigger the circuit
> >>>  breaker.  This will help avoid problems with automatic redial systems
> >>>  from congesting the network.  Accordingly, RTP flows halted by the
> >>>  circuit breaker SHOULD NOT be restarted automatically unless the
> >>>                  ^^^^^^^^^^
> >>>  sender has received information that the congestion has dissipated,
> >>>  or can reasonably be expected to have dissipated.
> >>>
> >>> and trying to understand why this is not MUST NOT. I'm trying to
> >>> reconcile this with the RFC 2119 definition of SHOULD NOT, which is
> >>>
> >>> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
> >>>  there may exist valid reasons in particular circumstances when the
> >>>  particular behavior is acceptable or even useful, but the full
> >>>  implications should be understood and the case carefully weighed
> >>>  before implementing any behavior described with this label.
> >>>
> >>> Could you help me understand when automatic restarts might be
> >> “acceptable or even useful”?
> >>
> >> As stated, automatic restarts might be acceptable or even useful if the
> >> sender receives information that the congestion has dissipated, or can
> >> reasonably be expected to have dissipated. This is why it says “SHOULD
> NOT
> >> … unless <reasons>” rather than “MUST NOT”.
> >
> >
> > Hi, Colin,
> >
> > On this one, I was getting tripped up on "or can be reasonably expected
> to
> > have dissipated" for an automatic restart, but if this means that an
> > implementer has thought about what has to happen before an implementation
> > does a restart with no user involvement, I can see that.
> >
> > I was getting tied up with the subsequent text, but perhaps I shouldn't
> > have been.
> >
> > Thanks for the help on that one.
>
> Thanks. Happy to clarify, if you have suggestions.


I think the point that had my shoelaces tied together was the incongruity
of an RTP implementation itself with expectations.

If you can come up with text that says something like "or can be reasonably
expected to have dissipated, based on the amount of time that has elapsed
since the circuit breaker has tripped", or whatever else you're thinking
of, that would have helped me.

(I'm assuming that the only thing an implementation has to work with when
it hasn't received information that congestion has dissipated, would be the
passage of time, but you'd know better what would be reasonable here)


> >>> Reading on, I'm wondering if this text is anticipating
> >>>
> >>>  It is recognised that the RTP implementation in some systems might
> >>>  not be able to determine if a call set-up request was initiated by a
> >>>  human user, or automatically by some scripted higher-level component
> >>>  of the system.
> >>>
> >>> but definitely want to understand what you're thinking here.
> >>>
> >>> I have a similar question about this text
> >>>
> >>>  ECN-CE marked packets SHOULD be treated as if it were lost for the
> >>>  purposes of congestion control, when determining the optimal media
> >>>  sending rate for an RTP flow.  If an RTP sender has negotiated ECN
> >>>  support for an RTP session, and has successfully initiated ECN use on
> >>>  the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD
> >>>                                                                 ^^^^^^
> >>>  be treated as if they were lost when calculating if the congestion-
> >>>  based RTP circuit breaker (Section 4.3) has been met.
> >>>
> >>> Could you help me understand why an implementation wouldn't do this?
> >>
> >> Because there are a small number of paths that misbehave when ECN marked
> >> packet are sent. I wanted to allow leeway for an end-point to not
> respond
> >> to ECN-CE marks on paths that spuriously mark packets, so falling back
> to
> >> the behaving as-if ECN was not used. I don’t believe this is harmful to
> the
> >> network, since the result will be the same as achieved by a non-ECN
> capable
> >> transport.
> >
> >
> > So, the scenario you're thinking of, is that you and I negotiated ECN
> > support for a session, I started marking packets, and a path started
> > marking packets with ECN-CE whether congestion was being encountered or
> > not, and I realize that's happening (by some logic not specified), so I
> > can't trust ECN-CE.
> >
> > Do I have that right? Assuming I’m close ...
>
> Yes, that’s one possible scenario. I can’t find it now, but I also seem to
> recall Apple reporting on strange experiences with ECN at a recent IETF.


Yum.


> > So, since I can't trust ECN-CE, I keep sending as if I wasn't getting
> > ECN-CE, and either that works (so, I did the right thing), or I manage to
> > cause enough congestion that it shows up in RTCP reports (so, I did the
> > wrong thing before, but I'll react to the less problematic RTCP reports
> and
> > do the right thing now, and that won't be any worse than what would have
> > happened if we hadn't been able to negotiate ECN support in the first
> > place).
> >
> > Do I have that right? Again, assuming that I’m at least close ...
>
> Yup.
>
> > I think what you're doing is "safe enough" that this isn't
> Discuss-worthy,
> > so I'll clear, but I wish the explanation of what's going on here was
> more
> > explicit. If you want to try to make that happen, I'm happy to chat
> further
>
> Happy to revise, if you think it would help. It’s better to make this
> clear, if we can.


So, at the risk of making an impressively long sentence longer ... I'm
thinking of something like

If an RTP sender has negotiated ECN support for an RTP session, and has
successfully initiated ECN use on the path to the receiver [RFC6679], then
ECN-CE marked packets SHOULD be treated as if they were lost when
calculating if the congestion-based RTP circuit breaker (Section 4.3) has
been met, unless the RTP implementation can determine that ECN-CE marking
on this path is not reliable.

Is that something like what we were saying in the previous exchange?

Thanks,

Spencer

--
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>