Subject: [tsvwg] General comments on slides-90-tsvwg-16.pdf

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 23 Oct 2014 07:07:16 -0600

Karen,

In your presentation,

  http://www.ietf.org/proceedings/90/slides/slides-90-tsvwg-16.pdf

you asked for comments on tsvwg on the material presented.  Here are
some general comments.

The procedures described appear to be concerned with avoiding T3
timeouts in as many scenarios as possible.  Stepping back and
thinking about that, I wonder what can be achieved by completely
eclipsing the T3 timeout procedure.  The procedures appear to
proceed from the assumption that T3 timeouts are evil and to be
avoided at all cost.

The evil appears to pivot on increased latencies in lossy network
(whether due to congestion or transmission errors) and not so much
on congestion avoidance procedures (cwnd).  The statement of evil,
if you will, appears to be: It takes a longer time for a T3 timeout
to occur than is necessary because better information about loss
can be available before the timeout ensues.

What RTO_MIN value are you using in your experiments?  For SIGTRAN
we have been using a RTO_MIN value of zero (0) for quite some time.
For example, ETSI TS 102 144 V1.1.1 (2003-05) specified the minimum
value for RTO.Min as 10 ms and specified with a granularity of 10 ms.
(Note that the common clock tick at the time was 10ms.)  This was
also mentioned in RFC4166/3.2.1.

There are a couple of well-known procedures that can be used to
mitigate spurious retransmissions when using a low RTO.min:

 - setting SACK_DELAY to zero (0) on both sides, or not penalizing
   a receiver for having a SACK_DELAY > RTO.

 - initiating an immediate HB probe for a destination when RTO
   approaches the granularity of the system clock to quickly
   recover a destination (especially when PMR is set to 0 or 1).

An extremely high RTO.min (e.g. 1 second) will make any procedure
that avoids a T3 timeout look good on the surface.

If your implementation is capable of setting RTO.min to zero, you
could try rerunning your experiments with an RTO.min of zero (0) to
determine whether falling back on T3 timeout is such a bad thing
after all.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 24 Oct 2014 08:43:59 +0200

Hi,

Please find comment below.

BR, Karen

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 23. oktober 2014 15:07
> To: Karen Elisabeth Egede Nielsen
> Cc: tsvwg WG
> Subject: General comments on slides-90-tsvwg-16.pdf
>
> Karen,
>
> In your presentation,
>

[Karen] Thanks  a lot for the comments. I appreciate that very much.

> The procedures described appear to be concerned with avoiding T3
timeouts
> in as many scenarios as possible.  Stepping back and thinking about
that, I
> wonder what can be achieved by completely eclipsing the T3 timeout
> procedure.  The procedures appear to proceed from the assumption that T3
> timeouts are evil and to be avoided at all cost.
>
(whether
> due to congestion or transmission errors) and not so much on congestion
> avoidance procedures (cwnd).  The statement of evil, if you will,
appears to
> be: It takes a longer time for a T3 timeout to occur than is necessary
because
> better information about loss can be available before the timeout
ensues.
[Karen] Yes I agree with this.
The issue is latency of course, but there are also CWND impacts of the T3
versus the FR.
However we have not qualified these yet. It is obvious that for the
situations where the unnecessary T3 occurs
there are pauses in the traffic and CWND reductions are thus not very
detrimental.

> What RTO_MIN value are you using in your experiments?  For SIGTRAN we
> have been using a RTO_MIN value of zero (0) for quite some time.

[Karen] We use RTO_MINs of 100 or 200 msecs in the experiments.
These numbers are taking from signaling network deployments at major
operator sites, including SIGTRAN.

> For example, ETSI TS 102 144 V1.1.1 (2003-05) specified the minimum
value
> for RTO.Min as 10 ms and specified with a granularity of 10 ms.

[Karen] This sounds misguided unless you have implemented means to undo
the effect of spurious T3 timeouts.
You may get away with some of the delay-ack impacts if you use immediate
SACKs
but you don't need a lot of congestion to make the RTT abruptly surge 10
msecs.
Unless you have implemented a new good RTO algorithm you then would have
problems, I think.

> (Note that the common clock tick at the time was 10ms.)  This was also
> mentioned in RFC4166/3.2.1.
>
> There are a couple of well-known procedures that can be used to mitigate
> spurious retransmissions when using a low RTO.min:
>
[Karen] Yes but such does not help with tail losses

> An extremely high RTO.min (e.g. 1 second) will make any procedure that
> avoids a T3 timeout look good on the surface.
>
> If your implementation is capable of setting RTO.min to zero, you could
try
> rerunning your experiments with an RTO.min of zero (0) to determine
> whether falling back on T3 timeout is such a bad thing after all.
>
[Karen] Our implementation supports RFC6458 and is used in High End Telco
networks.