[c-nsp] 837 and vbr-nrt size limitation

[Lobo]

Wow excellent response.  I think I might look into this kind of setup as 
well.  One concern I do have though is, if you're setting your vbr-nrt 
statement to 800 800, then isn't your download limited to only 800kbps?  
Or does the router ignore this and actually goes beyond the 800K when 
saying downloading things?  I just want to make sure that I'm not 
capping a 3M-7M DSL customer.

Jose Robles

Saku Ytti wrote:

>On (2005-03-30 09:39 -0500), Lobo wrote:
>
>  
>
>>We normally setup our DSL customers with an 837 and create a 
>>sub-interface off the ATM0 main interface.  We don't assign a vbr as we 
>>just leave it blank and let the DSLAM and ATM equipment take care of the 
>>shaping.  However, I wanted to apply a policy map and use LLQ on the 
>>connection outbound to our edge router.  To accomplish this I need to 
>>assing a vbr statement with hard coded PVC values so that the 
>>service-policy statement takes.  Upon trying to set this up I noticed 
>>that the router can only have a max of 800K as the size of the PVC.  
>>This represents a problem as our service is 7Mbps.  Is there any version 
>>of IOS that allows for a greater value to be entered or this some hard 
>>limitation on the router?  I tried 12.3(4)T11 non IP Plus.
>>    
>>
>
> I don't see this as a problem, your upstream is close to 800kbps anyhow,
>and what are you queueing, if not upstream. Can you do more guaranteed
>delivery for it than 800kbps? I strongly disagree.
>
> Now for a friendly advice, having delt with some bit in real life with 800
>series and QoS. You really _MUST_ configure 'tx-ring-limit' to reasonably
>low value, 1-5, calculate the serialization delay for worst case scenario.
>tx-ring is _FIFO_ buffer and if you get burst of lets say 20 ftp mass
>transfer packets, it's full of 1500 packets and your VoIP packets are sent 
>_after_ them, no matter how you've configured to QoS. So keep it small!
>
> Here's what I personally use for _my_ connection:
>class-map match-any high-priority
> match packet length max 200
>!
>!
>policy-map output-policy
> class high-priority
>  priority percent 75
> class class-default
>!
>interface ATM0.32 point-to-point
>  pvc 0/32 
>  vbr-nrt 800 800
>  tx-ring-limit 3
>  service-policy output output-policy
>!
>
> Company I work for chooses to use bit different method (basicly setting
>high-priority to precedence 5) but in my opinion choosing to prioritize
>small packets (perhaps 200 is even too large, but works for me) is
>absolutely killer method for QoS! Think about it, VoIP packets match, TCP
>ACK's to upstream bulk transfers match (no more laggy download when you
>upload in ADSL) interactive ssh session match (but not scp!). I'm extremely
>happy with this solution. I can upload digicam picture from my ADSL, keep
>playing mp3's over samba and still IRC over ssh with no latency that I can
>observe. Without this setting, using IRC over ssh is next to impossible
>when uploading. Due to upstream ACK's being dropped and required resends.
>
> Also be conservative with vbr-nrt, preferably it should be bit less than
>upstream in reality, since it must reflect truth what can be passed on
>upstream, if not, you will not be dropping non-priority packets early
>enough.
>
>HTH,
>--
>  ++ytti
>
>
>
>  
>