Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Routers/Switches restrictions for input streams

Hi,

We're facing problems while streaming intensive streams from our video streamer to the network.

Is there any restrictions in terms of bursts, packets size, time between packets, etc ?

Thanks.

6 REPLIES
New Member

Re: Routers/Switches restrictions for input streams

What kind of network connections are you dealing with? You may be having queue overflows or other issues, but without knowing what speeds and interfaces types you're talking about its a difficult question to answer.

In short, by default, there are no "restrictions" as such with streaming traffic. Routers and switches don't know anything over layer 3 (2 for switches) so they wouldn't know one type of data from another.

Check your interface statistics and see if you're losing any data... line errors, queue drops, buffer failures, etc...

Mick.

New Member

Re: Routers/Switches restrictions for input streams

Hi Mick,

thanks for your answer.

We're sending UDP packets which are MTU to ~13KB each, over 100BT lines.

The bitrate is from 1-10Mbits/s.

While sending bursts with no delay between the packets some packets were dropped by the routers.

Adding 1 milisec delay between packets sending improved the behavior as well as restrict to MTU size.

Is there any well known restrictions from the routers side ?

Thanks.

New Member

Re: Routers/Switches restrictions for input streams

UDP has very little overhead. MTU of 13KB on your packets just means that IP will fragment them and you'll have about 20 bytes less overhead per frame. Not sure how much you'll gain by having such large MTUs.

Adding the 1ms delay would probably keep the input queues from overflowing. Once again... have you checked your interfaces for queue overflows, errors? Have you checked for buffer failures.

I'm not sure if CAR is going to help you on this one since the UDP stream is being affected during input to the router... You'll either need to increase your input queues to handle bursts, or, if there aren't bursts but constant high BW streams, scale back your app to send more slowly (hence the 1ms delay).

Mick.

New Member

Re: Routers/Switches restrictions for input streams

Hi Mick,

Thanks again,

I just want to summarize what you adviced:

1) First we did check the buffer failures in our stack (WinSock) and it was OK. This lead us to suspect the routers.

2) The 13K packet size is due to OS restrictions for high bit rate.

3) As I understand there are no well known restrictions on the routers (For min delay between packets, etc.) and if we're facing problems we should increase the router's buffers, if we can or to slow the streaming rate, am I right ?

Thanks in advance,

Avi.

New Member

Re: Routers/Switches restrictions for input streams

1) The buffer failures I meant were on the router. SHOW BUFFER.

2) 13K shouldn't be a problem if you don't mind the IP fragmentation. Problem would be that if you drop a single fragment, you lose the 13K datagram.

3) Only increase the buffers to handle bursts. If the traffic rate is constantly higher than what the router can send, increasing the buffer size only increases latency and packet loss will still remain unchanged.

Mick.

New Member

Re: Routers/Switches restrictions for input streams

Look at committed access rate configuration for the interfaces.

239
Views
0
Helpful
6
Replies
CreatePlease login to create content