From: Christopher Morrow [mailto:[EMAIL PROTECTED] On Mon, Dec 1, 2008 at 3:54 PM, Fleischman, Eric <[EMAIL PROTECTED]> wrote: >> From: Tony Li [mailto:[EMAIL PROTECTED] >>>In some ways (and I admit that this is an imperfect analogy), >>>map-&-encap asks our hosts to trust their transport to a technology >>>that they can no longer interact with. How do we manage the >>>underlying network? >>>What happens when a host needs some exceptional service from the >>>network? This seems problematic and complicated, when the root >>>architecture of the network must be truly simple and elegant. >> >> How can hosts make requests of the network today? The only direct >> mechanism that I am aware of is QoS. The only other mechanisms that >> come > >RSVP - windows media player (or another media player I'm forgetting right now) does RSVP >reservation requests... fun fun fun!
Wow, Chris, this is really weird: I helped create parts of that product when I worked for Microsoft a bit over a decade ago. In my way of thinking, this is an example of the part of my posting (that was deleted above) where I mentioned out-of-band application admission control. Session scheduling does impact network load and therefore is relevant to the network. However, the only mechanism in practice that is available to hosts (that I am aware of) that can impact routing is QoS (e.g., the IP host routing option doesn't scale). The nature of my push-back to Tony is that I believe that the capabilities that Tony was ascribing to hosts aren't capabilities that actually are available to hosts at all. Rather, they are capabilities that are available to networks because of map-and-encaps (e.g., MPLS). Therefore, to argue against map-and-encaps because it encroaches on capabilities that exist for hosts (but which actually don't exist for hosts) is a spurious objection to map-and-encaps. Rather, I believe that the actual situation is a further testament to the prevalence of map-and-encaps today. _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
