On 01/26/2010 07:02 AM, Dunc wrote: > >> And you are perfectly right, as always. My choise of using the word >> "universal" was bad. With word "universal" I meant to use same network >> QoS API with different network technologies: ethernet, wi-fi, >> bluetooth etc. >> >> But we don't need to solve everything in one go, instead we can make >> small steps. The first step is to start pushing applications to >> classify their streams. That's the enabler to get some sort of QoS >> support, at least to inside kernel and to the next hop. With luck, in >> future it might get more widely used. >> >> I was hoping to base the classification on some standard, but there >> doesn't really seem to be one which would specify a complete solution. >> But that's ok, we can always create a de facto standard :) >> >> I'm curious how other operation systems handle this? Or is it a >> similar situation, nobody just doesn't use QoS for anything? >> >> > If applications set the QoS values, the who's to stop someone (for > example) writing a bittorrent client that marks all packets for the > highest priority as if they were VoIP or something? At this point all > the good work done in the applications is useless and the network admin > is going to have to not trust the QoS values and then attempt to > classify traffic by themselves, so it was all a waste of time. > > It's probably better to just always leave it up to the network devices IMHO. > > Cheers, > > Dunc > > I disagree. Some protocols are *very* hard to classify without looking into the application layer, which I have no interest in having network devices do (especially since in a multipath environment, they might not even see the entire flow). RTP, FTP-DATA, and TFTP are all very hard to classify because they don't use fixed port numbers. And even if you identify RTP, you still don't know if it's voice or video since that is signaled out-of-band. And yes, there will always be misbehaving users. They are a fact of life. That doesn't mean we should lobotomize the network. We don't have an authentication mechanism on ICMP Redirects or Source-Quench, for instance. Nor is ARP authenticated. BTW: Why not have Linux do DSCP/CS to 802.1p priority mapping on Ethernet drivers "out-of-the-box", regardless of whatever 802.1p tagging is actually being used or not (i.e. make it implied on the sending end-system). -Philip -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
