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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
