Re: [core] congestion control

Robert Cragie <robert.cragie@gridmerge.com> Tue, 12 January 2016 14:06 UTC

Return-Path: <robert.cragie@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765DA1B2A2C for <core@ietfa.amsl.com>; Tue, 12 Jan 2016 06:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 aOa_4c4smlD0 for <core@ietfa.amsl.com>; Tue, 12 Jan 2016 06:06:46 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 6DFD91B2A29 for <core@ietf.org>; Tue, 12 Jan 2016 06:06:45 -0800 (PST)
Received: by mail-lb0-x236.google.com with SMTP id cl12so55523913lbc.1 for <core@ietf.org>; Tue, 12 Jan 2016 06:06:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XI77+Q7BexsxNpHpKtIWhR71Ce5Ql02NTb88xQtVeUg=; b=daQTa5SHiqlr8bW2TPboVVuzmfsm2W+vlSUp4bTesEnUWz/I+vY8ZpQWJFmjYH9Muy EX3I3my1d37Ex5xJdZROR7SP54oLu6Fh1zh2o8Xo7YipxNV10w5tAghdIFIXRuQJBO+E yefoasoKKoxeqP3AZ0GrEZ05glnhDbGZpEZhInObbvWBzTlKyV97MaWT5t/KiIView3b nBDQydf08UYu2fbaG19gjPdomNcrXyTlEKrNcRHZ/2L1nmgO/EeOT1EBvdr0DjJq3BVw /JoOYKxt1fRSmysCd3yAq/8pg1ocMNWnOLZjXCscfaNgtn5wFLxh+XobBdeVxrzyBNWc MnAg==
MIME-Version: 1.0
X-Received: by 10.112.25.40 with SMTP id z8mr49874002lbf.13.1452607603579; Tue, 12 Jan 2016 06:06:43 -0800 (PST)
Sender: robert.cragie@gmail.com
Received: by 10.25.143.68 with HTTP; Tue, 12 Jan 2016 06:06:43 -0800 (PST)
In-Reply-To: <CAEgyW4q1jh=VO4fhki0jeNWJjWzkWjdDE7zAB3AjhcHPzvuoGA@mail.gmail.com>
References: <CAEgyW4q1jh=VO4fhki0jeNWJjWzkWjdDE7zAB3AjhcHPzvuoGA@mail.gmail.com>
Date: Tue, 12 Jan 2016 14:06:43 +0000
X-Google-Sender-Auth: KS29inseUxlsea2FPIak1BaEwTY
Message-ID: <CADrU+d+S=w=ahQtZt1eG1MOiSAeGo7jXUp3JnKF6hFg=z0LuZA@mail.gmail.com>
From: Robert Cragie <robert.cragie@gridmerge.com>
To: "R.Vinob chander" <vinobchanderr@ssn.edu.in>
Content-Type: multipart/alternative; boundary="001a11c3f5a435a6970529239093"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/jWnvKZEFTZIBiKUklOXDHr1BLw8>
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] congestion control
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2016 14:06:48 -0000

Hi Vinob,

Responses below, bracketed by <RCC></RCC>

Robert

On 9 January 2016 at 01:56, R.Vinob chander <vinobchanderr@ssn.edu.in>
wrote:

> Hi All,
>
>    May i get a clear understanding for the following in sec 4.7:
>
>  1. default value of NSTART is one. that means one outstanding interaction
> (meaning the responses for two different requests may arrive at the same.*
> am i right at this interpretation?*). *How does changing NSTART to a
> different value impact congestion control ?*
>

<RCC>
NSTART is just the number of outstanding interactions possible at the same
time (i.e. simultaneous). There are two sorts of interactions considered:

1) CON, expecting an ACK (messaging layer)
2) Request, expecting a Response (request/response layer)

The section basically states that for (1), the time an interaction is
outstanding is EXCHANGE_LIFETIME. It also says it is undefined in the case
of (2) but puts requirements regarding around not sending too much traffic
to a server.

A value of 1 means a client can only have one outstanding interaction with
any server at a particular time. So with NSTART=1, a client can't get two
different responses from the same server. A client may have multiple
interactions to *different* servers outstanding at any one time.
</RCC>


> 2. what is the significance of PROBING_RATE to congestion control?
>

<RCC>It has no significance to congestion control based on CON/ACK. It is
of significance to limit any attempt at congestion control using other
means above the messaging layer, which are undefined in RFC 7252. It is a
simple parameter aimed at limiting the amount of traffic which might be
sent if no response is received</RCC>

>
> 3. "The specific algorithm by which a client stops to "expect" a response to
> a Confirmable request that was acknowledged, or to a Non-confirmable
> request, *is not defined*."
>
> *why does the spec not define this?*
>

<RCC>Because it is really a higher layer matter. In addition to any lower
layer reliability mechanisms, for example, the CON/ACK reliability
mechanism, the application layer normally has its own methods for
reliability, usually involving expecting a response to a specific request.
This is specific to the application therefore cannot really be expressed in
a transfer protocol specification</RCC>

>
> 4. Unless *this is* modified by additional congestion control
> optimizations, it MUST be chosen in such a way that an endpoint does not
> exceed an average data rate of PROBING_RATE in sending to another
> endpoint that does not respond.
>
> *can you explain the above sentence? what "this is" in the sentence refer
> to? *
>

<RCC>"this" refers to "the specific algorithm". All this sentence is saying
is that whichever algorithm you choose, at the very least that algorithm
must not cause data to be sent at rates averaging more than
PROBING_RATE.</RCC>

-- 
> R. Vinob chander, B.E., M.E., (Ph.D)
> Assistant Professor, Department of IT
> SSN College of Engineering,
> Old Mahabalipuram Road
> Kalavakkam - 603 110
> Tamil Nadu, India
> www.ssn.edu.in
>
> Phone: +9144-27469700 , +91 44 27474844/45/46
> Extn: 370
> Mob: +91-9566101580
>
> ::DISCLAIMER::
>
> ---------------------------------------------------------------------
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. Views or opinions, if any,
> presented in this email are solely those of the author and may not
> necessarily reflect the views or opinions of SSN Institutions (SSN) or its
> affiliates. Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of this message without the
> prior written consent of authorized representative of SSN is strictly
> prohibited. If you have received this email in error please delete it and
> notify the sender immediately.
> ---------------------------------------------------------------------
> Header of this mail should have a valid DKIM signature for the domain ssn.edu.in <http://www.ssn.edu.in/>
>
>