Subject: [MMUSIC] draft-polk-mmusic-traffic-class-for-sdp

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Nov 2010 16:56:05 -0700

I've been thinking about this more lately. One of the reason this is so hard is because the DSCP can be different from the UA on one end of a SIP call than the UA on the other end of the same call. But the same remains true with this proposal. The traffic could be admitted on one end, and not admitted on the other - I don't know how this would deal with that. So it's not clear to me that creating the extra level of interaction of mapping these labels in SDP to DSCP at each end actually solves the problem. I do agree there is value in having visibility into the the QoS at the signaling layer and I can see value in the signaling being able to hint what sort of quality the user desired. For many any of the video calls I am on, I could care less about what happened to the video packets while on others I want it to work even at the expense of other applications on the network. 

One thing that is clear to me is that part of the difficulties in deploying DSCP based QoS is that so much was made flexible and left to local configuration that it is very hard to enable, deploy, or debug. Worse yet, it's hard for applications (imagine something like Apples Facetime or Skype) to even know what would be the right thing to do. The thing I don't like about this proposal is it builds yet more configuration and debug complexity into the system. It also sits on top of 6 classes that seem like sort of shaky ground to use as a foundation. For example, admitted and non admitted video would be more useful than admitted and non admitted voice in many networks just due to the larger impact of video on the network. Yes, i realize theses could be defined but there are not defined. Yet while if we just did a DSCP, it would be defined already. I realize the problem of SIP is cross domain yet the DSCP are not. I get a bit skeptical when I hear that Broadcast Video is not elastic , constant rate, and needs near real time forwarding -  I realize it just a label, but it's not a label that is consistent with what broadcast video is today. When we start getting to the difference of Telephony, Multimedia conferencing, and Real Time interactive - will, I have no clue what a applications should do. I'm imagine these labels were the best answer at the time they were done but they are the sort of thing that tends to just get more out of whack with reality as time goes on. When writing applications, I tend to not to to think if the application is a  Telephony application or not but instead pick the category that would give my application the desired behavior. Unfortunately as you follow that path, when you look at how the DSCP values end up mapping onto something like 802.11, it starts to look like randomly choosing some DSCP that is high med or low is close enough. 

I like the problem you are trying to solve. I wish I had better advice on "if you just did X, you would easily solve this" but I don't. I don't see how this is going to really help things - it just seems to add one more layer of indirection to exactly the parts that were already hard. One thing you could do to hedge your bets on this is make it so that this could signal both the traffic class as it does now and could also signal the DSCP. 

PS - As you can imagine, I also think the categories in tsvwg-rsvp-app-id are wrong and will result in it not being particularly useful but that somewhat separate topic. If we ever want to discuss that in this WG, well I think here is the right place to discuss the categories part of it but there's not enough minutes in the day for me to go argue why the categories are wrong in tsvwg.