Subject: [core] congestion control

From: "R.Vinob chander" <[email-masked]>
Date: Sat, 9 Jan 2016 07:26:04 +0530

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/>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 12 Jan 2016 14:06:43 +0000

Hi Vinob,

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

Robert

> 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>

> *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>

> exceed an average data rate of PROBING_RATE in sending to another
> endpoint that does not respond.
>

<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>

--