- From: "Mohammed P.A Ashraf " <ashraf.mohammed AT lycos.com>
- To: "Andreas Jungmaier" <ajung AT exp-math.uni-essen.de>
- Cc: discussion AT sctp.de
- Subject: Re: [SCTP-Discussion] Some general queries on implementation
- Date: Thu Oct 25 15:05:01 2001
- List-id: SCTP Discussions <discussion.sctp.de>
- Organization: Lycos Mail (http://mail.lycos.com:80)
Thanks a lot for ur quick reply.The fact is that iam very new to this
transport protocol and am trying to understand this by going thru the
impelmentation(along with RFC). And bcoz of this I may not be able to come
with the patch immediately..Although i shall be thinking in these lines as i
go thru the ref. implementation.
thanks,
ashraf
On Thu, 25 Oct 2001 12:52:24
Andreas Jungmaier wrote:
>
-----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-----
>
Make a difference, help support the relief efforts in the U.S.
http://clubs.lycos.com/live/events/september11.asp
Archive powered by MHonArc 2.6.19+.