SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] Some general queries on implementation


Chronological Thread 
  • From: Andreas Jungmaier <ajung AT exp-math.uni-essen.de>
  • To: discussion AT sctp.de, "Mohammed P.A Ashraf " <ashraf.mohammed AT lycos.com>
  • Subject: Re: [SCTP-Discussion] Some general queries on implementation
  • Date: Thu Oct 25 12:52:02 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: University Essen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday, 24. October 2001 13:06, Mohammed P.A Ashraf wrote:
> hi,
>
> I have some queries reg the implementation of sctp avilabe on sctp.de
> page. I appreciate if someone cud clarify my queries:
>
> 1. Is there any upper limit on the amount of user data that can be queued
> up at the tx side?
> If n/w is congested and transmitter is not able to send any more data, How
> long should it keep collecting data & when should it inform the ULP?

We will gently modify the API described in the file "sctp.h" so that
you will be able to set a queue length limit, and get a notification,
once it is passed.

> 2 Is there any upper limit on the highest TSN that can be received at the
> receiver or is it that any TSN would be received & stored in the buffer??
> similar to upper window in sliding window protocol.

Currently not. That might be a neat idea, though. I think Randy Stewart
has implemented something similar in his reference implementation.

> 3. If "don't bundle flag" is NOT set for particular ULP DATA request, then
> how long should a DATA packet wait in the bundling module to enable
> bundling for this chunk.

The handling of this flag may currently be buggy. So chunks are bundled
on retransmission now, anyway. And for initial transmission, there is no
default waiting time. Chunks are sent at once. That might change in the
future, though.

> 4 Looks like MAX size if INIT or INITACK is limited to max-sctp_pdu(less
> than 1500 in this case), will there be any case (as mentioned in the RFC)
> where INIT/INITACK can be larger than 1500 due to variable -length nature
> of cookie.

Well, our implementation is still a prototype, and does not support
hundreds of addresses. So there is no need to have larger INITs.

> 5. shudn't the size of buffer that accepts datagram from raw socket be
> much higher than path_mtu( since if the othe rend is not doing any
> fragmentation, the receiving side can receive messages greater than path
> mtu size).

Hmmh, I am actually not sure...that needs investigation.
Would you be willing to try and send me a patch ?

Regards,
Andreas

- --
- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier | _
Computer Networking Technology Group | ASCII ribbon campaign ( )
University of Essen | - against HTML email X
http://www.exp-math.uni-essen.de/~ajung | & vcards / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE71+7oXAsLBNOCSsARAiRSAJ48Xe6yzn39MS2aF+9Qe4AnbP1SZQCgpFqp
qljP/Uo/bLXplLEfNYqc6D8=
=4BPB
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.19+.

Top of page