Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)

Varun Singh <varun@callstats.io> Thu, 05 May 2016 20:43 UTC

Return-Path: <varun@callstats.io>
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 21DEC12B01F for <avt@ietfa.amsl.com>; Thu, 5 May 2016 13:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io
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 XkJ2SAKFPvFK for <avt@ietfa.amsl.com>; Thu, 5 May 2016 13:43:48 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 E00A312D13C for <avt@ietf.org>; Thu, 5 May 2016 13:43:45 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id u64so110101787lff.3 for <avt@ietf.org>; Thu, 05 May 2016 13:43:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7UvgNrAoK6tK4An0J1V7c6LPn8bwpuZRvAVrwhz4hyE=; b=KeeRPAGX16fuWuojqOtPB8FOax/ZYz0RFtWQ/C9s1WOK386X1DFFXHROd4zsB+bWSX ntPdnLSZMXQmwsBC+ZbwgWI29snipd9ClCtEouXnXTI+3O+TwgZK7xIt1rbSCfRLqRKk djvwddZaFylkvSioMKUOJJukmw5pf3FzvHIq0=
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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7UvgNrAoK6tK4An0J1V7c6LPn8bwpuZRvAVrwhz4hyE=; b=Ldc0mu5whEepNrnKr/ymCLhnQFLl+1RnkGfta9VM0iiuNaklJZqlPtX1gc+y1KfoKv bEI1JIEyrn3IFbd1UBfCrsmcIXGdik8yqC9pL6MOYAHg+77LkecIodTsu6C9dkBFPy1R GbFhaqi+tWJLQcsr37rtqQzIax6wTKZiQxDpXLZ8cfYyJT81dDk4qQlm6nuPJiP9RraY x1ibHknP4kgWrfK+7kuEZH6rLkN2Q4+zjm/3H7DzBphmzMFYDuCN3S9NJTSgtTql/rWw p4kqU47l+YUtt7RQVEh8F3XmrzUmI1N0ifIkyVOfMot96cJkJXy5oZWLgw2bGylNIF0S hppw==
X-Gm-Message-State: AOPr4FX5hmJcQnrEvYOHPHyIJ5o6n5aq8IBric4EdDXlbawmhmxJ9ue+ZUzOXewl4W7wbdcQCCMpUcOz1GXEaQ==
X-Received: by 10.112.137.104 with SMTP id qh8mr6847970lbb.144.1462481023982; Thu, 05 May 2016 13:43:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.77.34 with HTTP; Thu, 5 May 2016 13:43:24 -0700 (PDT)
In-Reply-To: <2EC09917-2E05-407D-AA7F-38C73B179C4B@kuehlewind.net>
References: <20160503120321.7534.26562.idtracker@ietfa.amsl.com> <32C2F93E-9CB9-4645-9C42-320AA8B24ED5@csperkins.org> <2EC09917-2E05-407D-AA7F-38C73B179C4B@kuehlewind.net>
From: Varun Singh <varun@callstats.io>
Date: Thu, 5 May 2016 23:43:24 +0300
Message-ID: <CACHXSv6vggo7KN1HOqQyjbzro6Eq0zGNcfJ9poKnfpBipBn7Vw@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/hj4cS-eyZjbliPhow7GypRzGo0k>
Cc: avtcore-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org, The IESG <iesg@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [AVTCORE] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-avtcore-rtp-circuit-breakers-15=3A_=28with_DISCUSS_and_COMMEN?= =?utf-8?q?T=29?=
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: Thu, 05 May 2016 20:43:50 -0000

Hi Mirja,

see inline.

Regards,
Varun

On Wed, May 4, 2016 at 1:52 PM, Mirja Kuehlewind (IETF)
<ietf@kuehlewind.net> wrote:
>
> > Not sure I agree. The circuit breaker needs to treat lost and CE-marked packets the same as a congestion control algorithm, and the ECN specifications say that the response to CE marks needs to be the same as the response to loss.
>
> I disagree, given the explanation above that ECN-CE marking indicate that all traffic have been transmitted correctly. It’s only an input for a control mechanism/loop and should not be used as input for a circuit breaker, at least not the same way as loss it used.
>
> You could calculate the loss and ecn ratio separately and e.g. lower the k value if there is also a high level of CE marks. However, only CE marks without loss should not trigger a circuit breaker. This is also what ietf-tsvwg-circuit-breaker says:
> "If Explicit
>       Congestion Notification (ECN) is enabled [RFC3168], an egress
>       meter MAY also count the number of ECN congestion marks/event per
>       measurement interval, but even if ECN is used, loss MUST still be
>       measured, since this better reflects the impact of persistent
>       congestion.“
>

First, I believe the draft assumes ECN-CE should be considered as lost
packets in addition to the lost packets.

Second, I am not sure the text from the tsvg-circuit-breaker applies
in this case. Because the calculation in section 4.3 takes place at
the sender. And the  sender receives the ECN-CE counter from
the receiver in an RTCP XR report (RFC6679).

In RFC6679: the receiver reports the cumulative lost packets and
cumulative ECN counters. So at the sender, there may not be
sufficient information to say if the ECN-CE packets were
accompanied by loss or not.


> >
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> Few more minor comments:
> >>
> >> 1) reference [I-D.ietf-tsvwg-circuit-breaker] should be normative
> >
> > This was discussed in relation to Ben’s AD review. I think you can implement the RTP circuit breaker without reading the TSV draft, so informative seems correct. However, I don’t much care either way.
>
> I will double-check this; was not aware of any previous discussions here. I still think it should be normative...
>
> >
> >> 2) How is the loss rate in 4.3 calculated if some (but no all) RR are
> >> lost?
> >
> > There’s no obvious way for the receiver of the RRs to know that some were lost, so the calculation will proceed as if the reporting interval was longer.
>
> Hm… what’s about using the (difference of )total number of losses instead?
>

As Colin indicated there is no way to know that the report was lost.

In (RFC3550), the fraction lost is defined to be the number of packets
lost divided by the number of packets expected since the last report.
And the formula in Section 4.3 does not rely on all receiving all
reports. Furthermore, the RTT and fraction lost plugged into the
formula are based on the same report.

Is the concern that the fraction lost may not be sufficiently
indicative if the preceding RTCP RR was lost?



-- 
Founder, CEO, callstats.io
http://www.callstats.io
Analytics and Optimizations for WebRTC.

We are hiring: www.callstats.io/jobs/