Support post release

Support work based on widespread usage and feedback from that usage is normal. The vast majority of this feedback should be reviewed by the Product Owner and handled. Some of it may be beyond the scope or current vision for the product and won't go further. Others may end up on the Product Backlog and appropriately prioritized. Some work may end up high on the backlog, while others will be much lower.

If the Product Owner released an increment, then I would expect that it meets a minimum bar for quality. However, if a large number of urgent issues arose because of that deployment, there seems to be a disconnect between the quality expectations of the team (including the Product Owner) and the quality expectations of the stakeholders. It would probably be beneficial for the team to understand this gap and close it quickly so that way Sprints can regularly result in potentially releasable increments of their product.

Generally speaking, though, if the Scrum Team is expected to do maintenance and support work, it's probably a good idea to ensure that there is time for this during Sprint Planning. I've found it helpful to realize that, of the working hours in a Sprint, only a fraction is spent on productive, non-overhead work. Of that, you need to allocate a portion to activities like refinement. You would also allocate a portion to handle incoming support requests. If you have historical information on the frequency of support requests and how much time is spent, that can be useful, but you would want to monitor that over time. If you start to spend a lot of time on support requests, you may want to find ways to do planned product work with the intent of driving down those requests.

The Scrum Guide says:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

What's so special about those "support tickets"? What stops them from being ordered on the Product Backlog with all the other scope needed to improve the product? Do "support tickets" expose a problem with the quality of releases, perhaps?

Since scrum team is sprinting, what is advisable whether stop sprint to provide quick support to ticket or reduce the sprint duration to provide fast response to ticket or support ticket has to wait till next sprint start as they sits into product backlog.

The length of a Sprint should remain as constant as possible in order to provide consistency and predictability.  The Developers should plan a Sprint according to what is in the Product Backlog at the time the planning is done.  If new items come into the Product Backlog (such as support tickets) they should be validated and ordered by the Product Owner.  The Scrum Guide states

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.

The Product Owner should make a determination if the support item is worthy of immediate attention and then discuss this with the Scrum Team.  The Developers can decide if it can be pulled into the current Sprint without impacting their ability to accomplish the Sprint Goal.  Depending on that decisions, the appropriate discussions ensue. 

There is no "right way" to do this.  Each one should be unique.  

I would discuss Service Level Agreements with the Scrum Team and communicate those to the stakeholders.  That allows you to set expectations with the stakeholders on how issues found will be addressed.

thanks all for insights. In nutshell, sprint should continue with same length to ensure consistency and predictability. All support tickets should go to product backlog for PO to prioritise. Developer can provide support as outcome from sprint.