Microsoft problems?

[Chaim Fried]

Anybody know of any prolonged outages at Microsoft (MSN messenger)today?

RE: VoIP QOS best practices

[chaim fried]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On 
 Behalf Of Stephen J. Wilcox
 Sent: Monday, February 10, 2003 12:56 PM
 To: Bill Woodcock
 Cc: [EMAIL PROTECTED]
 Subject: Re: VoIP QOS best practices
 
 
 
 On Mon, 10 Feb 2003, Bill Woodcock wrote:
 
  
Looking for some links to case studies or other 
 documentation which
describe implementing VoIP between sites which do 
 not have point to
point links.  From what I understand, you can't 
 enforce end-to-end QoS
on a public network, nor over tunnels.  I'm 
 wondering if my basic
understanding of this is flawed and in the case 
 that it's not, how is
this dealt with if the ISPs of said sites don't 
 have any QoS 
  policies?
  
  QoS is completely unnecessary for VoIP.  Doesn't appear to 
 make a bit 
  of difference.  Any relationship between the two is just FUD from 
  people who've never used VoIP.
 
 My conclusion too when I looked at this a couple years back. 
 
 However, its important that the backbone is operating 
 properly ie not saturated which I think should be the case 
 for all network operators, theres a requirement tho if the 
 customer has a relatively low bandwidth tail to the network 
 which is shared for different applications, its probably a 
 good idea to make sure the voip packets have higher priority 
 than non-realtime data... (this 
 last comment is a suggestion, I've not actually tested this in a real 
 environment, low b/w lab tests tend to exclude other traffic flows)

I have tested this in lab settings for video over IP (t1 with multiple
384k calls and data) , and came to that same conclusion. While it works
on the tail and needs to be implemented bi-directionally (which never
happens). There is no reason to implement QOS on the Core. Having said
that, there still seems to be too many issues on the tier 1 networks
with pacekt reordering as they affect h.261/h.263 traffic. 

 
 Steve
 

RE: VoIP QOS best practices

[chaim fried]

Good point. Later version from the larger video-conferencing Gateway
manufacturers, seem to do a better job (better- not perfect) handling
reordering. So clearly there seems to have been issues with the
applications buffering itself. Out of order packets are considered lost,
so whatever you would put your tolerance threshold for loss will
determine your tolerance for ou of sequence? I would measure in terms of
.0x% for my customers, who expect toll-quality video.  

Based on the traces we've examined, most of the time it's not that the
latency is too much to be rectified with proper buffering. However,
again we don't want anybody reordering our packets.

 -Original Message-
 From: Leo Bicknell [mailto:[EMAIL PROTECTED]] 
 Sent: Monday, February 10, 2003 11:44 AM
 To: [EMAIL PROTECTED]
 Subject: Re: VoIP QOS best practices
 
 
 In a message written on Mon, Feb 10, 2003 at 01:19:08PM 
 -0500, chaim fried wrote:
  happens). There is no reason to implement QOS on the Core. 
 Having said 
  that, there still seems to be too many issues on the tier 1 
 networks 
  with pacekt reordering as they affect h.261/h.263 traffic.
 
 I've got a question about this issue.  Many networks reorder 
 packets for a number of reasons.  At least once before I've 
 attempted to measure the effects of this reordering on a 
 number of forms of traffic, but I have never understood the 
 particular effects on VOIP traffic.
 
 Indeed, the two times I was asked to investigate this for 
 video people it turns out the video receivers /had no ability 
 to handle out of order frames/.  That's right, get one packet 
 out of order and the video stream goes away until it 
 resynchronizes.  Now, I realize reordering should not happen 
 to a large percentage of the packets out there, but it also 
 seems to me any IP application has to handle reordering or 
 it's not really doing IP.
 
 So what's the real problem here?  Are the VOIP boxes unable 
 to handle out of order packets?  Do the out of order packets 
 simply arrive far enough delayed to blow the delay budget?  
 What percentage of reordered packets starts to cause issues?
 
 -- 
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
 PGP keys at http://www.ufp.org/~bicknell/
 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org