Re: Clarify SCTP max packet size.

Michael Tüxen <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
On Jul 3, 2009, at 9:38 PM, Gomes, Rui Filipe Efigénio, VF-PT wrote:

> Dear Sirs,
>
> A major equipment vendor (A) states on their documentation that:
> "The max packet size usable by SCTP is 1416 bytes."
What does this mean?
1500 (MTU) - 20 (IP header) - 12 (SCTP common header) - 16 (SACK  
chunk) - 16 (SATA chunk header) - 20 (whatever)

This would mean that the SCTP stack might only be able to send user  
messages of the
length 1416. Depending on the upper layer and your application, this  
might be OK.
>
> According to RFC2960 and RFC 4960:
> "An SCTP receiver MUST be able to receive a minimum of 1500 bytes in  
> one SCTP packet.  This means that an SCTP endpoint MUST NOT indicate  
> less than 1500 bytes in its initial a_rwnd sent in the INIT or INIT"
>
> Even if we took the "full" 1500 Ethernet IPv4 packet SCTP will have  
> a max of 1466 bytes.
A full ethernet frame would have an IP packet of length 1500 byte, so  
typically
an SCTP packet of size 1480, which means 1468 for chunks.

However, the limitation of max. use message sizes is different from  
limiting the
a_rwnd.

The statement in the RFC is that the a_rwnd must be 1500 or larger on  
the INIT and INIT-ACK.
The receiver should handle full sized frames for 1500 MTU links.

If the a_rwnd is smaller than 1500, you will have serious interop and  
performance
problems. So you might want to clearify first if you are talking about  
the
maximum user message size or the maximum advertised receiver window  
and also
about the maximum size of a received user message. Reassembly is  
optional...
>
> I tested and it seems that SCTP packet with longer size is being  
> discarded. Node never acknowledges its reception.
>
> This means that major vendor A is violating the RFC?
> I'm having an IOT issue between two major vendors and I think that  
> vendor A is not following SCTP RFCs (old and new).
>
> Please confirm.
>
>
> Thanks in advance and best regards,
> Rui Gomes
>
> Source:
> http://tools.ietf.org/html/rfc2960#page-67 6. User Data Transfer  
> paragraph 4, http://tools.ietf.org/html/rfc4960#page-73 6. User Data  
> Transfer paragraph 4)
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran
>
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.