Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Sat, 5 Oct 2002 11:37:40 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 9:18 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> Sorry for the lengthly response: but you persist ;)
[TOLGA] No, problem at all :) But I will send the reply in several chunks,
so that we and others can follwo it.
> 
> Tolga Asveren wrote:                                          
>                        (Fri, 04 Oct 2002 19:58:47)
> > Brian,
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Friday, October 04, 2002 6:37 PM
> > > To: Tolga Asveren
> > > Cc: [email-masked]'
> > > Subject: Re: [Sigtran] M2PA V6: T7
> > > 
> > > 
> > > Tolga,
> > > 
> > > Tolga Asveren wrote:                              (Fri, 04 
> > > Oct 2002 16:39:48)
> > > > > 
> > > > > It will be a cold day in June before SCTP addresses this. 
> > >  I tried for
> > > > > over a year to get bounded delay into SCTP.  But you are 
> > > welcome to try on
> > > > > TSVWG.  Until then, M2PA needs T7.
> > > > [TOLGA]I still think one can control bounded delay for SCTP 
> > > with RTO.max,
> > > > Path.Maxretans and Assoc.Maxretrans. With RTO.max=150ms 
> > > Path.maxretrans=2,
> > > > Assoc.maxretrans=2, propogation delay will be kept under 
> > > 900ms (for lost and
> > > > retransmitted messages, it might be a bit higher with a 
> very small
> > > > possiblity).
> > > 
> > > You are forgetting that successful HEARTBEAT/ACK clears the
> > > peg counts.
> > > 
> > > Even still RTO.max = 150ms is not recommended in the wild.  
> > > Others have
> > > found that even 200ms is hard to get down to.  Also 
> > > Path.Max.Retrans = 2
> > > and a Assoc.Max.Retrans of 2 (and I assume you mean two 
> > > interfaces) means
> > > that your association cannot handle a temporary network delay 
> > > of 300ms.
> > [TOLGA]Why do you think it can't handle a delay of 300ms? 
> It will take
> > 150+150+300+300=900ms till the association 
> fails.(Path.MaxRetrans = 2,
> > Assoc.MaxRetrans = 4, two interfaces)
> 
> Read above--you said: Assoc.MaxRetrans = 2.
> 
> Also, you calculation may be wrong unless you also in RTO.Min at 150ms
> (which would be rather worthless).  Also, you said RTO.Max of 150ms.
> Where did you get 300ms from?  RTO maxes out at 150ms.  Even with
> Assoc.Max.Retrans = 4, the longest it will take is 150ms+QDR+150ms+
> QDR+150ms+QDR+150ms.  Remember that there is a Queueing Delay before
> Retransmit (QDR) that gets worse with each retransmit due to a closing
> congestion window.  But at the minimum you get 
> RTO.Min+2*RTO.Min+RTO.Min+
> 2*RTO.Min.  If RTO.Min is 50ms, that's 300ms anyway.
[TOLGA] Yes, I did wrong calculation, for that you are right. Take RTO.min
also 150ms. Then it will take 150ms*4 = 600ms. I think this is reasonable. I
think when T3 expires, regardless of cwnd value ,DATA chunks to be
retransmitted, which fit into a single packet will be sent. So, I don't
expect QDR to play a role, while detecting the loss of the association.
> 
> Also, it is foolish to lower RTO.Max below 200ms.  Why?  Because the
> max sack delay is 200ms recommended and 500ms maximum.  You will be
> retransmitting (and throttling for congestion) once every two packets
> because t3-rtx will fire before the far end sends it delayed SACK.
> This means that you will have 1 peg against each destination half of
> the time.  When a real failure comes you can fail in 2*RTO.Min or
> in your case 100ms.
[TOLGA]As you stated it is just a recommended value, like the other
recommended values in RFC2960, I expect it to be suitable for the big-I
Internet, but we don't expect M2PA to run on the big-I Internet, so one can
set it to a lower value. Furthermore that delayed acknowledgement algorithm
to be followed is a SHOULD, not a MUST.
Even if one follows it, when there is bidirectional data transfer, most
probably this won't cause a problem at all, because while sending data for
unacknowledged received data SACK will be bundeled to the package. Even for
unidirectional traffic, if averageRTT+peer SCTP response time = ~50ms(I
think even this is high for average RTT on a reasonable private IP network),
only with very low message rates, let's say -considering the variable delay-
below 10msg/sec, one might retransmit because of delayed acknowledgement
policy.
But for that issue, the real solution is IMO to set ack timer to a
reasonable value. 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran