Re: QoS considerations

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Black" == Black David <Black_David@emc.com> writes:
    >> This essentially says to use RSVP to signal the QoS for the resulting
    >> ESP packets that are generated. This signal travels to the first edge
    >> routing
    >> of the diffserv cloud [called the "diffedge" device in 2998] (and I
    >> would imagine no further), causing the edge router of the ISP to enact
    >> some admission control based upon (dest, proto, SPI#) [see
    >> RFC2207]. The packet is then admited to the proper diffserv queue and
    >> has the appropriate DSCP stamped on it.

    Black> This causes the ISP's edge router to have to classify traffic
    Black> based on SPI#.  That's an example of microflow classification, and
    Black> a rather unusual one.  An alternative model would be to apply the

  unusual? What's usual on a framework that is barely deployed :-)
  SPI is 4 bytes at 4 bytes further into the packet than TCP/UDP port pair..

    Black> DSCPs that the ISP is expecting at the customer's VPN gateway that
    Black> is facing the ISP; the ISP then classifies traffic based on DSCP
    Black> and conducts admission control on the basis of that
    Black> classification.

  Yes, that could be done as well. I would tend to think of doing this when
the enterprise itself is doing diffserv already.

    Black> Both solutions require the signaling to pass from the VPN gateway
    Black> to the ISP, and are subject to failure if it doesn't (e.g.,
    Black> something in between discards RSVP traffic or decides to rewrite
    Black> the DSCPs because it can).

  At which point, one gets "Best Effort" :-(

    Black> If IPsec is running end-to-end, so the IPsec implementations are
    Black> on hosts attached to a customer network rather than on an
    Black> ISP-facing VPN gateway, things get more complicated, and RFC 2998
    Black> is certainly one approach to a solution.  Another is to use
    Black> whatever's appropriate for the customer network and have an
    Black> ISP-facing device reclassify the traffic and apply the DSCPs as
    Black> appropriate for the customer's policy for usage of the ISP.  This

  Yes. My impression is that is really doesn't matter where the device that
translates RSVP -> DSCP is. CPE or ISP-located, doesn't matter.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPKYwR4qHRg3pndX9AQF82gP/dxF0Oz+Ka5pxZtuTTzAu1J+uRatPr4M9
8ZcIZhl4Ir68bkKoaIE96VKS96fgYQEsy/XbEgjuJEw4CdnkWUTDyo2zwuPPH8y0
DfkDKhgwseCzvb9XKdObKy7ltg8Fnt7j6hvNK/7luZpmfuD3ShiIcUuKeJaHysFH
DpQuNK9keHg=
=UWoY
-----END PGP SIGNATURE-----