Re: QoS considerations

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

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


  I think that you have an excellent summary of the discussion so far, 
thank you.
  Your points about negotiating PHBid's is well taken.

  (Note that PHB = Per-Hop Behaviour, not Pointy Haired Boss)

  My concern with using RFC2983 when it comes to typical VPN and end-to-end
deployments is that I'm really not clear what a host/gateway is supposed to
do to signal the desired QoS. Specifically, when the boxes are customer
located rather than located at the ISP (a la PPVPN).

  My understand of DiffServ is that DSCPs are really enterprise specific.
So, there really isn't anything I can put in my packets to get the resulting
PHB that I want. My opinion is that the only useful model is therefore
RFC2998.

  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.

  Note that there is nothing that gateway itself puts on the packet to pick
the resulting DSCP (unless there is diffserv within the customer enterprise,
which seems rather doubtful to me for some time). The only communication is
via choice of different (dest, proto, SPI#) for different flows. So that
implies actually negotiating multiple tunnels.
  
>>>>> "Black" == Black David <Black_David@emc.com> writes:
    Black> Finally, RSVP is also in the "sometimes appropriate" category
    Black> - by now, this theme should be clear.  RSVP is a useful tool
    Black>  in some situations, but it doesn't handle admission control
    Black> by itself, and one cannot count on it always being available

  To clarify this statement - RSVP just signals the desire for admission
control.   

    Black> or appropriate to use.  Relying on RSVP as the only solution
    Black> to providing QoS will result in not being able to support
    Black> QoS in many network environments.

  I'm sure that this is true. (I've seen RSVP in operation myself, and I 
do not know anyone personally that has ever deployed it) 
  What other options are there?

  One concern is when/if we define an attribute to describe the desired QoS
on the SA bundle-pair being created is that the two ends may in fact have to
use different (locally configured) mechanisms.

]       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

iQCVAwUBPJpYxoqHRg3pndX9AQHyNQP+Pxpy4rqpF6b1tgBKuMXUTdDvtqYGL+kh
H4SFJGE33xI1JdFnCMmswy46FCEWiGpq4owf9BtMBLjMsPCAXiQ+Tl1aXgcZmVRQ
hwZ9bknVoQtV4c2ImHNJgz3J2pc7xPEfgplDtWklUXOtwSXmDldIJZrllNQ99oz4
ykY0vlLxB3M=
=YcH8
-----END PGP SIGNATURE-----