[AusNOG] Crashes all round on Tuesday

[Paul Brooks]

On 1/07/2015 3:11 PM, Mark Smith wrote:
> On 1 July 2015 at 14:56, Mark Smith <markzzzsmith at gmail.com> wrote:
>> On 1 July 2015 at 12:33, Ross Wheeler <ausnog at rossw.net> wrote:
>>>
>>> I had several links went down at 10:00 (give or take a few seconds) - well,
>>> not mine so much as my upstream - and it's been blamed on this issue.
>>>
>> So from a little bit of Human Computer Interaction (HCI) I studied
>> many years ago, I remember that humans will wait for some sort of
>> response for between 3 to 5 seconds. So if the period of your packet
>> loss and the retransmission to recover from it is short enough, the
>> humans effected may notice a slight delay, but they won't take any
>> remedial actions themselves (i.e, they won't push the submit button
>> again, and won't complain about it.)
>>
> This can also be particularly useful to know when cutting a set of
> links over from an old piece of equipment to a new one. 3 to 5 seconds
> is a bit tight to move the link, you can push people's response
> expectations out in the outage notice (e.g., "between 7 and 8 am, we
> will be conducting network maintenance. During this period, you may
> encounter system delays of up to 5 to 10 seconds). I think asking
> people to wait any longer than 10 seconds means this is a service
> impacting outage and should be scheduled out of normal operating
> hours.

FWIW, the ITU recommendation for synchronous links (SDH, OTN etc)* considers that the
link has to be down for at least 10 seconds for it to qualify as an "unavailable" and
for the equipment to generate an alarm. If it wasn't down for at least 10 seconds, it
was never down. Once back up, it has to be up for at least 10 seconds before the
equipment should clear the alarm.

if you can unplug the cable and plug it back in within 10 seconds so there's no SNMP
trap to the NMS, you might just get away with it ;-)


*G.827 Availability performance parameters and objectives for end-to-end international
constant bit-rate digital paths
*G.8201 Error performance parameters and objectives for OTN