[core] congestion control
"R.Vinob chander" <vinobchanderr@ssn.edu.in> Sat, 09 January 2016 01:56 UTC
Return-Path: <vinobchanderr@ssn.edu.in>
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 41AD41A0060 for <core@ietfa.amsl.com>; Fri, 8 Jan 2016 17:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.322
X-Spam-Level: *
X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 D1B6LrO7IWN5 for <core@ietfa.amsl.com>; Fri, 8 Jan 2016 17:56:05 -0800 (PST)
Received: from mail-ig0-x244.google.com (mail-ig0-x244.google.com [IPv6:2607:f8b0:4001:c05::244]) (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 294351A005B for <core@ietf.org>; Fri, 8 Jan 2016 17:56:05 -0800 (PST)
Received: by mail-ig0-x244.google.com with SMTP id ik10so9308970igb.1 for <core@ietf.org>; Fri, 08 Jan 2016 17:56:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ssn.edu.in; s=ssn; h=mime-version:date:message-id:subject:from:to:content-type; bh=QPxKp2ZLbIMosvKNP5gOSIVhvPrsAPzkPuIKdAUAxPo=; b=gBkxGTOKM3wgsIGRSHAZejGfrObnCGcwvyquCxANFu+q2Ajj0qwc3DZMYLj8PgxvAe BeeVHCwetNqe96QbKKgn0gEQ4Ie2mMCUfn5u3e4PcOQyufV7hoFhfvWgwbBDDpP9IhYX exvlQkjpqnY7E3LTLn4AmdniU8ctgkT/YkHcY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=QPxKp2ZLbIMosvKNP5gOSIVhvPrsAPzkPuIKdAUAxPo=; b=ajpjbvTLVDrRBjcu37/FlTqBM7AZk7ed6EhrJ2SIOpKFWStTQljfoayMi7eFDRMXH1 xAPKY9l/Q+hTY46wMQaKPxeA9HbJmW7xYPdDEYUiIivZw7lIoY/3Olxd0MM+78FsxvSe O6gtdLQOpxFc0HLT9+VXEmsc9eMG9iDeXk97lnJlX5cHiIsyxQMQVBO3tOKmnFEyqVYv PUeewO5tevkA/WaxvruvbkMAJ1z4CmZoBogB/Qwc+fG7MUKtFP+AOGydIhHhR2eSaZTB 1ekctJrQToGns+fVkzQjCqXQRr5dp5zDSZS5njgZ/0ja8+3kusKlCpITk0tM6eB07VcY TGnA==
X-Gm-Message-State: ALoCoQmwy80gRbxZBj+eiylDtNJRbXQpnXp4AEcoJ3uhG3f1R9H+Zjnil7gZ1gpugptgqnuTqpBynN0eCjmbhwmrfr54S88354QU7LJ1RfWLbiIWbczX2BtM+tpNHVY4mrSOKAQkbzdkb+q2w6n3u7l3eWlnN8Ch3g==
MIME-Version: 1.0
X-Received: by 10.50.28.37 with SMTP id y5mr1876780igg.93.1452304564471; Fri, 08 Jan 2016 17:56:04 -0800 (PST)
Received: by 10.79.120.216 with HTTP; Fri, 8 Jan 2016 17:56:04 -0800 (PST)
Date: Sat, 09 Jan 2016 07:26:04 +0530
Message-ID: <CAEgyW4q1jh=VO4fhki0jeNWJjWzkWjdDE7zAB3AjhcHPzvuoGA@mail.gmail.com>
From: "R.Vinob chander" <vinobchanderr@ssn.edu.in>
To: core@ietf.org, Robert Cragie <robert.cragie@gridmerge.com>
Content-Type: multipart/alternative; boundary="089e01538c36abe9120528dd018b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/249r9ZfvRtMMDpXdYM4toO8aJqc>
Subject: [core] congestion control
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Sat, 09 Jan 2016 01:56:07 -0000
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 ?* 2. what is the significance of PROBING_RATE to congestion control? 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?* 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? * -- 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/>
- [core] congestion control R.Vinob chander
- Re: [core] congestion control Robert Cragie