RE: Notices to ASPTM message mapping

"Kolomaznik Jan" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
Ad 1) I think, it will be better if any recommendation word (like
SHOULD) will be used in talking about a possibility of ASPTM messages
mapping on any SCTP stream carrying data traffic. I agree that in
situations where more than one data traffic streams are used the
minimization of possible packet loss cannot be so high, but in cases
where only one data traffic stream is used it is 100%.

Ad 2) If ASTPM Ack messages will use a data traffic SCTP stream, I do
not see any practical reason for this type of restriction. - But if
ASPTM Ack messages will be transmitted on SCTP stream 0, there is a
theoretical possibility that ASPTM message will be evaluated earlier
than previously sent data message(s). This possibility could happen both
in ASP Active and ASP Inactive procedures. So my meaning is, when a
ASPTM not Ack message used data traffic SCTP stream, the ACK message
should use data traffic SCTP stream also.
The second thing is that from protocol theory point of view the Ack on
different stream than acknowledged message looks not good. So if there
is not any practical reason for changing of stream for Ack message, the
Ack message should use the same stream.

Jan Kolomaznik

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Monday, May 29, 2006 8:21 PM
To: Kolomaznik Jan
Cc: [email protected]
Subject: Re: [Sigtran] Notices to ASPTM message mapping

Kolomaznik,

Kolomaznik Jan wrote:
(Mon, 29 May 2006 13:16:15)
> 
>    Hello,
> 
>    I  would like to share any findings we have made during
implementation
>    of  SUA  in  IPSP environment. Our work has been based on RFC 3868
and
>    draft-ietf-sigtran-sua-implementor-guide-03.txt.  Please send
comments
>    if you find out we are not true.
> 
> 
>    1)  Problem  with  mapping  of  ASPTM messages on SCTP stream. -
Which
>    stream  number  to  use?  ... there are two relevant paragraphs in
RFC
>    3868, sua-implementor-guide-03 does not solve this question.
> 
>    RFC 3868, section 4.2.1:
> 
>    "All non-Transfer messages, with the exception of ASPTM, BEAT and
BEAT
>    Ack messages SHOULD be sent on SCTP stream '0'.  ASPTM messages MAY
be
>    sent  on  one of the streams used to carry data traffic related to
the
>    Routing Context(s), to minimize possible message loss."
> 
>    RFC 3868, section 4.3.4.3:
> 
>    "It  is possible for the ASP to receive Data message(s) before the
ASP
>    Active  Ack message as the ASP Active Ack and Data messages from an
SG
>    or  IPSP  may  be  sent  on  different  SCTP streams.  Message loss
is
>    possible,  as the ASP does not consider itself in the ASP-ACTIVE
state
>    until reception of the ASP Active Ack message."
> 
> 
>    So  ASPTM messages MAY be sent on any SCTP stream, but generally it
is
>    better  to  send they on any traffic stream (not on SCTP stream 0).
It
>    practically means, a sending entity MAY send it on any SCTP stream
and
>    a  receiving  entity  SHOULD  be  prepared  to  receive it on any
SCTP
>    stream.

Yes.  In general, an implementation should be prepared to receive any
message
on any stream.

> 
> 
>    2)  Mapping  of  ASPTM  Ack  messages on SCTP stream ... I think it
is
>    general  principle  to  be  received  message acknowledged on the
same
>    stream as an acknowledged message has been received - but this
general
>    principle is not enforced in RFC 3868 or
>    sigtran-sua-implementor-guide-03.  This  situation  may  leads  to
the
>    situation following the next example:
> 
>    ------------ ASP Active/SCTP stream 1 ----->
> 
>    <-------- ASP Active Ack/SCTP stream 0 ----

Yes, that is possible.  Did you see any reason why it would be necessary
to
restrict the situtation further?

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.