Subject: Re: [Sigtran] [M2UA]Clarify M2UA flow control/congestion procedure

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 1 Jul 2009 02:54:54 -0600

Steven,

An SG implementation could, for example, detect flow control
toward the ASP at SCTP by checking and thresholding the amount
of send buffer fill for SCTP.  Another is to set lifetimes on
SCTP messages and detect messages that are acknowledged beyond
the reasonable lifetime.  Either could be translated into
receive congestion or processor outage as you surmize.
Processor outage is better because not only data transmission
but control between MTP2 and MTP3 has been impaired, and simply
because some operators require that SS7 equipment not issue
SIB.  Another approach would be to have one mechanism (e.g. M2UA
HEARTBEAT on an IID stream) cause SIB (for that IID) but another
mechanism (e.g. M2UA HEARTBEAT on stream 0) detect command flow
control which could separately trigger SIPO (for all IIDs).
Application HEARTBEAT is likely the most portable approach.

--brian

ZHOU Minggang wrote:                           (Wed, 01 Jul 2009 09:48:20)
> 
>    Hello Brian,
> 
>    According to RFC3331 procedures, which reads:
> 1.5.6  Flow Control / Congestion
> 
>    It is possible for the M2UA layer to be informed of the IP network
>    congestion onset and abatement by means of an implementation
>    dependent function (i.e. an indication from the SCTP).  The handling
>    of this congestion indication by M2UA is implementation dependent.
>    However, the actions taken by the SG should be in accordance with the
>    appropriate MTP specification and should enable SS7 functionality
>    (e.g. flow control) to be correctly maintained.
> Question: As a SGP, How to implement this function?  Is it appropriate for SGP 
> to send out SIB or SIPO?
> Which choise is better?  Or is there any other advice?
> Thanks a lot!
> 
>    Steven

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jul 2009 08:35:28 -0600

Steven,

Some early implementations of SS7 link hardware could not receive
at anything close to 1 Erlang and would generate SIB at regular
inteverals to throttle receive traffic down to a dribble while
still maintaining conformance with specifications.  A way to keep
these poor implementations out of the network was to impose a
network-specific requirement that no signalling link generate SIB.
Some specifications never removed the requirement over the years.

--brian

ZHOU Minggang wrote:                (Fri, 03 Jul 2009 14:02:27)
> Hi Brian,
> 
> Thanks a lot for your clarfication! 
> One more question:  Why do some operators require that SS7 equipment
> not issue SIB, for business reason or else?
> 
> Best regards, 
> Steven

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jul 2009 21:26:31 -0600

Rui,

It is not the place of the IETF or the SIGTRAN mailing list (the WG is shut down)
to proclaim conformance on any implementation.  That said:

1. Tell vendor A to learn to read before they come back.

2. Tell vendors ~A to quit complaining and set their MTUs to 1400 for now.

--brian

"Gomes, Rui Filipe Efigénio, VF-PT" wrote:                                         (Fri, 03 Jul 2009 21:38:27)
> Dear Sirs,
> 
> A major equipment vendor (A) states on their documentation that: 
>  "The max packet size usable by SCTP is 1416 bytes."
> 
> 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. 
> 
> 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)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Gomes, Rui Filipe Efigénio, VF-PT" <[email-masked]>
Date: Mon, 6 Jul 2009 10:52:55 +0200

Brian,

Thanks for the help and sorry for the inconvenience. 
I did read the RFC but since it is a really major vendor I wanted to be really sure (could other paragraph that I didn't found say otherwise). 

Prior sending e-mail I've already did your suggestions, but vendor B is saying that they can not change MTU - they set the MTU=1500 since is the minimum allowed value (they cannot have a bigger MTU either).

If you are curious I can disclose to you only more info.

Best regards,
Rui Gomes

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: sábado, 4 de Julho de 2009 4:27
To: Gomes, Rui Filipe Efigénio, VF-PT
Cc: [email-masked]
Subject: Re: Clarify SCTP max packet size.

Rui,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "David Laight" <[email-masked]>
Date: Mon, 6 Jul 2009 12:19:25 +0100

> Prior sending e-mail I've already did your suggestions, but 
> vendor B is saying that they can not change MTU - they set 
> the MTU=1500 since is the minimum allowed value (they cannot 
> have a bigger MTU either).

The problem I see is that the MTU is usually a property of the
'ethernet' interface, not of the protocol. So the IP stack should
be able to process receive messages that are the size of the
largest MTU on the media - which is usually 1500 bytes from the
'ethertype' for ethernet networks.
(the mtu field for the interface itself may have to include the
mac addresses and ethertype - so would be 1516)

Setting the interface mtu to a smaller value is likely to cause
bigger interworking issues.

IIRC all SCTP packets are required to have the IP DNF (do not
fragment) bit set. So an ICMP error could be used at the IP
layer to force a smaller MTU - as is done to avoid PMTU blackholeing
when there is a PPPoE link.

	David

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you really need to

---

From: "Gomes, Rui Filipe Efigénio, VF-PT" <[email-masked]>
Date: Fri, 3 Jul 2009 21:38:27 +0200

Dear Sirs,

Please confirm.

Source:

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Jul 2009 06:19:47 -0600

David,

David Laight wrote:                           (Mon, 06 Jul 2009 12:19:25)
> bigger interworking issues.

RFC 1122: (page 59)

 The MTU of each physical interface MUST be configurable.

If Vendor B cannot configure their interfaces for 1400 then
they are violating the requirements for IP hosts, which, IMHO
is far worse than Vendor A refusing to accept SCTP packets
larger than a certain size.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Jul 2009 06:23:24 -0600

Rui,

"Gomes, Rui Filipe Efigénio, VF-PT" wrote:  (Mon, 06 Jul 2009 10:52:55)
> 
> Prior sending e-mail I've already did your suggestions, but vendor B
> is saying that they can not change MTU - they set the MTU=1500 since
> is the minimum allowed value (they cannot have a bigger MTU either).

Tell Vendor B to learn to read (RFC 1122) before coming
back as well.  MTU must be configurable on an interface.

> If you are curious I can disclose to you only more info.

Email me off-list.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "David Laight" <[email-masked]>
Date: Mon, 6 Jul 2009 14:12:09 +0100

> back as well.  MTU must be configurable on an interface.

The problem I see here, is that it is the path-mtu that
has to be 1400, not in interface mtu.
All you are likely to be able to do on 'B' is set the interface mtu.

IIRC IP only requires 576 (or so) bytes, 1500 is the standard
ethernet mtu, but for PPPoE the mtu is a few byte shorter (1492?).
so if SCTP actually requires 1500 it will never work over PPPoE.

Any equipment attached to a physical ethernet cable that can't
receive maximal length ethernet packets seems very non-conformant!
(Using it probably requires that ALL systems on that network use
the smaller mtu.)

	David

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 6 Jul 2009 23:11:34 +0200

> so if SCTP actually requires 1500 it will never work over PPPoE.
There is no requirement for an MTU to be at least 1500 bytes.
The point is that SCTP must not announce less then 1500 bytes in
the a_rwnd of the INIT and INIT_ACK. And the SCTP layer should be
able to receive packets of at 1500 bytes. If the lower layer
only supports less, then it does not affect this, since the
smaller packets are also supported.
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 6 Jul 2009 23:23:39 +0200

> "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.
> "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"
>
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.
>
> 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.
>
>
> 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)

---

From: <[email-masked]>
Date: Tue, 7 Jul 2009 08:50:57 +0200

Dear all,

Just to add with the SCTP bundling feature. If the "SCTP MTU" is 1500, and the system is bundling messages at the SCTP level, you should have the risk to segment at the IP level (because of the IP header). So it is not efficient to bundle sctp messages and to segment them at the IP level. Some vendors limits "SCTP MTU" to avoid that. This is only the Maximum transmission unit. If one SCTP message to transmit is greater, they will segment it.

Regards.

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Michael Tüxen
Envoyé : lundi 6 juillet 2009 23:24
À : =?ISO-8859-1?Q?=[email-masked]; _Rui_Filipe_Efig=[email-masked]; _VF-PT=22?=
Cc : [email-masked]; [email-masked]
Objet : Re: [Sigtran] Clarify SCTP max packet size.

What does this mean?

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.
> Even if we took the "full" 1500 Ethernet IPv4 packet SCTP will have a 
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...
> Transfer paragraph 4) _______________________________________________
> Sigtran mailing list
> [email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 7 Jul 2009 18:51:09 +0200

On Jul 7, 2009, at 8:50 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Dear all,
>
> Just to add with the SCTP bundling feature. If the "SCTP MTU" is  
> 1500, and the system is bundling messages at the SCTP level, you  
> should have the risk to segment at the IP level (because of the IP  
> header). So it is not efficient
The MTU SCTP uses is the link layer MTU minus the headers for IP and  
SCTP.
I have not seen an implementation which bundles at the SCTP layer and  
than
needs to fragment at the IP layer. I would consider this broken...
> to bundle sctp messages and to segment them at the IP level. Some  
> vendors limits "SCTP MTU" to avoid that. This is only the Maximum  
> transmission unit. If one SCTP message to transmit is greater, they  
> will segment it.
>
> Regards.
>
> Pierre
>
> messages of the length 1416. Depending on the upper layer and your  
> application, this might be OK.
>>
> 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.
>
> limiting the a_rwnd.
> 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...
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Jul 2009 12:02:41 -0600

Michael,

Err, the MTU SCTP uses when bundling is the Association Path MTU.  It
subtracts IP header and SCTP header sizes from this Path MTU only when
considering how many chunks can be bundled.

--brian

Michael Tüxen wrote:                        (Tue, 07 Jul 2009 18:51:09)
> On Jul 7, 2009, at 8:50 AM, <[email-masked]> 
> <[email-masked] > wrote:
> 
> >Dear all,
> >

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 8 Jul 2009 00:43:33 +0200

Hi Brian,

sorry, I do not understand what you want to say...

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Jul 2009 17:19:44 -0600

Michael,

I believe I was correcting your statement.

--brian

Michael Tüxen wrote:                                 (Wed, 08 Jul 2009 00:43:33)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 8 Jul 2009 13:55:39 +0200

Brian,

I'm trying to figure out what my mistake is...

Are you saying that the SCTP layer will construct SCTP
messages which needs to be fragmented at the IP layer?
(not considering the case where the path MTU drops
and retransmissions are required)

I think Pierre assumed that SCTP constructs SCTP messages
of 1500 bytes which have no space anymore for the IP
header when sent over an 1500 byte MTU ethernet interface.
And I do not think that this is the case. Am I wrong?

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Jul 2009 06:13:30 -0600

Michael,

> >>>Err, the MTU SCTP uses when bundling is the Association Path MTU.
> >>>It subtracts IP header and SCTP header sizes from this Path MTU
> >>>only  when considering how many chunks can be bundled.

> >>>Michael Tüxen wrote:                        (Tue, 07 Jul 2009
> >>>>The MTU SCTP uses is the link layer MTU minus the headers for IP
> >>>>and SCTP.  I have not seen an implementation which bundles at the
> >>>>SCTP layer and than needs to fragment at the IP layer. I would
> >>>>consider this broken...

Look at what you wrote.  What I am saying is:

 1. The MTU SCTP uses is _NOT_ the link layer MTU: it is the
    association path MTU.

 2. The MTU SCTP uses is _NOT_ minus the IP and SCTP headers: it
    is the association path MTU.  This is the MTU used in all
    SCTP calculations.

 3. When SCTP goes to bundle chunks, the packet space available
    for bundling chunks is the association path MTU minus the IP
    and SCTP headers.

To summarize, when the association path MTU is 1500 (typical),
the value 1500 is used for the MTU in calculations (windows,
threshold, etc.)  However, when SCTP goes to bundle chunks,
the room available for chunks is (1500 - IP hdr - SCTP hdr).

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: <[email-masked]>
Date: Wed, 8 Jul 2009 14:25:58 +0200

Brian,

I agree your vision : bundling must take care of the length of the message.
But during my tests of different SIGTRAN stacks, I observe an unwaiting result. Because of bundling, the IP MTU was oversized and so the IP packet was segmented. We ask for a correction. So normally it is working fine now.

Pierre

-----Message d'origine-----
De : Brian F. G. Bidulock [mailto:[email-masked]] 
Envoyé : mercredi 8 juillet 2009 14:14
À : Michael Tüxen
Cc : ALLEGRET PILAUD Pierre RD-CORE-ISS; VF-PT Gomes Rui Filipe Efigénio; [email-masked]
Objet : Re: [Sigtran] Clarify SCTP max packet size.

Michael,

To summarize, when the association path MTU is 1500 (typical), the value 1500 is used for the MTU in calculations (windows, threshold, etc.)  However, when SCTP goes to bundle chunks, the room available for chunks is (1500 - IP hdr - SCTP hdr).

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Jul 2009 07:32:47 -0600

pierre.allegret,

It is not a vision, it is how it works.  Where do you find
these implementations that are 10 years behind the times?

--brian

[email-masked] wrote: (Wed, 08 Jul 2009 14:25:58)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 8 Jul 2009 18:12:16 +0200

> the room available for chunks is (1500 - IP hdr - SCTP hdr).
I agree, I was just sloppy in writing...

Best regards
Michael