Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestion control/rate limiting issues)

[Magnus Westerlund <[e-mail]>]

Hi,

See inline.

Hancock, Robert wrote:
> hi,
> 
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[e-mail]] 
>> Sent: 16 June 2006 15:27
>> To: Hancock, Robert
>> Cc: [e-mail]
>> Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: 
>> congestion control/rate limiting issues)
>>
>>
>> Hancock, Robert wrote:
>>> Hi all,
>>>
>>> comments on the congestion control/rate limiting issues
>>> (M1 and in fact L16-part as well):
>>>
>>>> -----Original Message-----
>>>> From: Magnus Westerlund [mailto:[e-mail]] 
>>>> Sent: 01 June 2006 15:23
>>>> To: [e-mail]
>>>> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09
>>>>
>>>> M1. Congestion Control
>>>>
>>>> This affects text not only in 5.3.3 but also 7.1.3 and 
>> possibly other 
>>>> places. But I do have a general concern that the 
>> congestion control 
>>>> measurements described in the specification is underspecified.
>>>>
>>>> First in 5.3.3 I don't see any normative minimal values, or even 
>>>> recommended values for T1 and T2 that will be safe to 
>> deploy on the 
>>>> internet. I don't find it acceptable that the developer needs to 
>>>> investigate which values that are safe to use and which are 
>>>> not. There 
>>>> should also be some criteria documented for when it is 
>>>> acceptable to go 
>>>> beyond these values. So my concern here is that the 
>>>> retransmission runs 
>>>> havoc and create way to many packets to be sent.
>>> This is a fair point. I suppose it is impossible to get away
>>> permanently without giving concrete numbers in this case.
>>>
>>> In terms of what sort of values to use and how to describe the
>>> constraints on them, I think a good model to follow is probably
>>> the SIP INVITE transaction specification (17.1.1.2 of rfc3261)
>>> which says [fortunately the timer names are the same...]
>>>
>>> "  The default value for T1 is 500 ms.  T1 is an estimate of the RTT
>>>    between the client and server transactions.  Elements 
>> MAY (though it
>>>    is NOT RECOMMENDED) use smaller values of T1 within 
>> closed, private
>>>    networks that do not permit general Internet connection. 
>>  T1 MAY be
>>>    chosen larger, and this is RECOMMENDED if it is known in advance
>>>    (such as on high latency access links) that the RTT is larger.
>>>    Whatever the value of T1, the exponential backoffs on 
>> retransmissions
>>>    described in this section MUST be used."
>>>
>>> and later that T2 should be 64*T1. In our case, 500ms seems 
>> a reasonable
>>> default also; I think T2<=64*T1 since there is a separate 
>> bound on the
>>> T2 value from the signalling application (see the second 
>> paragraph of
>>> 5.3.3). I would be tempted to relax the NOT RECOMMENDED 
>> clause, since
>>> a smaller timeout would be valid and possibly quite useful 
>> on a wider
>>> range of networks, in particular Internet-connected networks but
>>> where it is known that the Query should be answered within the local
>>> network. Comments and text suggestions welcome.
>> I think this is reasonable start. It seems to be to be a good idea to 
>> allow the adaptation of the timers based on feedback from the 
>> peer. It 
>> seems possible to use the GIST query and the response to measure the 
>> current RTT. Allowing modification of the timers to track 
>> that value + 
>> some processing delay + fudge factors seems one way forward.
> 
> ok, we can work on including this.
> 

Good, lets see how complex this becomes and if it is worth the effort. 
So I would suggest that the WG thinks up some strawmen to discuss around.

[snip]
> 
> that would be too easy ... ;-)
> 
> the end result of the ICMP discussion (as I read it) has been that
> there *are* no default parameters in the ICMP spec. (The relevant
> section is 2.4(f) of rfc4443.) There is a definition of a set of
> parameters (bucket rate N and size B), but the closest one gets to
> parameters is "For example, in a small/mid-size device, the possible 
> defaults could be B=10, N=10/s." which is about as tentative as it
> comes. And I would not say that the numbers are that useful; what to
> reuse would be the text that says
> - it's configurable
> - take into account where you are in the network
> (and implicitly that limiting based purely on inter-packet timers
> or absolute bandwidth caps are not useful, which was what was removed
> compared to the previous version of the spec.)
> 
> There have been analysis documents in the distant past about message
> rates, but only applying to QoS (based on RSVP experience) and even
> they have been controversial because they depend so strongly on
> assumptions
> about refresh reduction. Now we have a wider range of signalling
> applications, so the situation is likely to be even less clear.
> 
> the best advice to implementors I can think of would be to say that 
> *) the bucket size (B) should be related to the number of signalling
>    sessions that the node is expected to support
> *) the rate should allow the bucket to be discharged in a second
> 
> (and these would be SHOULD starting points).
> 
> That still doesn't give an actual number, but it does relate the number
> to a more 'objective' system sizing parameter that implementors will
> have to think about anyway.
> 

Well, could we provide some conservative numbers that are quite certain 
to no screw up the network completely even in some worst case scenario 
and provide those as default values with instructions how one may modify 
them. I am still concerned about the risk of misconfiguration leading to 
serious issues. An interesting complication that might be shown is that 
the maximum load from GIST will only show up when there is need for a 
massive amount of D-mode traffic, like when attempting to do local 
repair and refresh the routing state. The unfortunate things here is 
that these are situations when there is a high risk that there anyway is 
quite a heavy load on the network due to route changes etc.

I fear that we can't do much better than some conservative values and 
recommendations for how to configure this if you think you know what you 
are doing. The next step seems to be a fully adaptive scheme which will 
not be simple.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis