Maybe this is not a good example. In my opinion, there are two possible reasons to use QoS relay. 1 Due to the technical limitation of IP layer QoS, P2P users have to use relay. 2 Due to non-technical reasons like the cost of implementing IP layer QoS solution, IP layer QoS can not meet the requirement of P2P users. So P2P users have to use relay wether the operator likes it or not.
I am not very familar with the IP layer QoS. I not sure about reason 1. Anyway, no matter what reason, QoS relay exists. -- Kind regards Lichun Li ZTE Corporation Enrico Marocco <[email protected]> 发件人: [email protected] 2009-10-28 00:43 收件人 lichun li <[email protected]> 抄送 "[email protected]" <[email protected]> 主题 Re: [alto] ????: Re: New draft on relay usage for ALTO lichun li wrote: > I understand. Routing policy can result in TIVs, if the policy > considers factors other than latency. > I think the technical limitation could be the reason of TIVs too. > Resolving TIVs caused by technical reasons in IP layer may be hard, > but resolving with relay is easier. Could you provide examples of such routing layer limitations that would be best addressed at the application layer? > Take AS routing as an example. Suppose both AS B and AS C can route > traffic from AS A to AS D. AS B charges a higher price for routing > traffic, but routing through AS B is fast. Suppose AS A's operator's > will is: a flow to AS D should route through AS C (slow but cheap) if > QOS meets the application's requirement, otherwise route through AS B > (fast but expensive). If using routing policy only, out-bound router > must sense the exact QOS requirement of every traffic flow and the > latency of AS path. So only configuring routing policy at IP layer may > not fulfill the will of operator entirely. Both routing policy and > relay should be used to fulfill operator's will. I would say that's what RSVP was invented for. In which way do you think a solution based on application-level relays would work better? -- Ciao, Enrico _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
smime.p7s
Description: Binary data
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
