Re: [Sigtran] M2PA T7 timer again

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 03 Apr 2003 09:42:22)
> Brian,
> Please see some comments/questions below.
> (not with the intention of starting T7 discussions
> again, personally I still don't think that diversion
> from MTP2 about how to use T7 was necessary at least
> not mandatory)
> --- "Brian F. G. Bidulock" <bidulock@openss7.org>
> wrote:
> > David,
> > 
> > David Lehmann wrote:                                
> >                                 (Thu, 03 Apr 2003
> > 09:30:09)
> > > Brian F. G. Bidulock wrote:
> > > > Fiddling with SCTP parameters has its own
> > problems.  See the SCTP
> > > > applicability statement.  In general SCTP
> > applications should no mess
> > > > with SCTP parameters to avoid implementing
> > application-level timers.
> > > 
> > > So the authors are recommending (requiring?) that
> > M2PA implementations
> > > use the default SCTP parameters as specified in
> > RFC 2960, section 14?
> > 
> > I don't see any reason why M2PA cannot work with
> > those settings.
> > 
> > Do you?
> [TOLGA]I wouldn't use receommended values in RFC2960,
> because I prefer to detect remote host failures as
> quick as possible (not with T7) by adjusting SCTP
> parameters, considering that I have a low latency IP
> network.

That's not a reason why M2PA cannot work with section 14
settings.  Do you see any reason why M2PA cannot work with
section 14 settings?

> > 
> > Also, the settings cannot be negotiated and the one
> > end of the
> > link cannot place requirements outside the
> > recommended range onto
> > the other end of the link.
> [TOLGA]Those are just recommended values for the big-I
> Internet case. In a private network, one is free to
> choose any value for those parameters and I would
> consider this configuration rather than putting
> requirement on a remote peer.

Sack delay at the peer can be 500 ms regardless of the latency
of your network.  Are you sure you are not placing requirements
on the peer by deviating from the recommended values?  What
values are you using?

> > 
> > > 
> > > (My understanding was that those parameters were
> > designed
> > > to make SCTP Internet friendly and not necessarily
> > to preclude
> > > SCTP users from fiddling to meet certain timing
> > requirements.)
> > 
> > What network need not be Internet friendly?
> > 
> > What IETF standard cannot be?
> [TOLGA]It is clear that IETF documents should consider
> the big-I Internet case, but this is exactly the
> reason why those recommended values are for the big-I
> Internet case and are not necessarily
> suitable/mandatory for private IP network case.

So, M2PA, being an IETF document, should also consider the big-I
case?  If M2PA cannot work on the big-I, why are we writing an
IETF document?

And what do we really mean by the big-I case?  Is it not
sufficient that TCP uses the same network (whether intranet or
internet)?  Adjusting SCTP parameters would then cause SCTP to
compete harmfully with TCP on the same network to the detriment
and degradation of TCP users.  Isn't it enough that some
"intranet" and "internet" traffic shares the same backbone?
M2PA was meant to be run between nodes at a distance from each
other.  Who owns a backbone that doesn't carry big-I traffic?

Does not draft-ietf-sigtran-signalling-over-sctp-applic-07.txt
speak to this?  Why did you not comment on this draft at LC if
you felt so strongly that the recommended parameters were so
unusable?

I think M2PA has to work with the parameters recommended for
SCTP.  As it may take minutes for SCTP to detect failures with
recommended parameters, T7 or some equivalent is necessary.  RFC
2960 does discuss message life times.  A per-message T7 could
easily be accomplished by setting the life time on each message
to T7.  Then M2PA does not depend upon deviating from
recommended parameters.  It will function equally well (all
other things being the same) regardless of whether it is your
low latency "intranet" or the big-I, or both running on the same
backbone.

--brian

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran