Enrico Marocco 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?
Woops, of course I meant DiffServ, sorry. It may have been a Freudian slip though ;) -- Ciao, Enrico
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
