hi pekka,
it is interesting to hear your opinion on these issues. i would like to
point out a few things:
- there have been a number of discussions about the bandwidth broker concept
in the past and the disadvantages are known. (my personal opinion) if it
boils down to the protocol details then the difference between the rsvp
architecture with a pep/pdp and a bandwidth broker is not hudge. the central
entity which performs the authorization (or policy) decision was already
mentioned.
- from a signaling protocol point of view there is little difference between
path-coupled and path-decoupled signaling in many cases. even path-decoupled
signaling is path-coupled in some sense - you do not want to signal your
messages to networks where the data traffic will never flow through. one big
difference is the discovery mechanism. you are certainly right with your
observation that you could use a number of different discovery mechanisms to
communicate with devices along the path. if we can learn something from rsvp
with this respect then it should that multiple mechanisms for discovering an
node along the path has to be supported - not only router alert options. i
think such a decision would increase the number of usage scenarios.
btw, you might not know about the path-decoupled signaling (pads) bof (see
http://www.ietf.org/ietf/03mar/pads.txt) where people spoke about reusing
path-coupled signaling protocols in order to provide path-decoupled
signaling.
- denial of service issues with the router alert option: it is true that
router alert option processing is slower than packets which do not have the
router alert option set. however, i am not sure whether this is truely a big
issue based on the most recent information i saw (see
http://www.welzl.at/research/projects/ip-options/).
furthermore, i always had the impression that other mechanisms even
introduce more denial of service risks. for example: if you have your
bandwidth broker example then you need to deal with dos issues against this
device as well (and there are plenty of them). basically, you need to
address denial of service issues at any place, regardless of the specific
solution.
- firewall issues: you argue that an operator might not allow users to open
pinholes. why not? if you authenticate and authorize users then you can make
a decision which user is allowed to open a pinhole. furthermore, you already
do it today with more complex mechanisms based on sip signaling and midcom.
it would be worth to have a discussion on the following issue:
* path-coupled signaling is very benefitial if you have complex topologies
where routing symmetry causes packets towards different destination
addresses to hit different firewalls/nats. melinda shore raised this issue
in midcom (i guess for the first time). you can find her draft at
http://www.watersprings.org/pub/id/draft-shore-friendly-midcom-01.txt.
* will people deploy firewalls in the future? (particularly since people
tunnel everything through http)? (my personal opinion is yes, they will.)
- nat issues: why do you think that nat handling is trickier? in fact the
case of a data receiver being behind a nat is (based on our investigations)
rather a nice case since you are assured that the data packets traverse this
nat (if you publish the obtained ip address, transport protocol + port as
your contact address). with a data receiver behind a firewall (in case of
complex topologies and routing asymmetry) things are more complicated
(without making additional assumptions). you mention some ipv6 specific
solutions that would fix the problem automatically. could you please
elaborate?
- you mention a few issues with regard to qos and charging. this is a
complex issue which we (engineers) are not really good in making a decision.
i have read a number of papers by prof. odlyzko (see for example
http://www.dtc.umn.edu/~odlyzko/doc/pricing.architecture.pdf). these papers
are nice to read but it is hard to estimate how individual issues raised in
these documents influence our work (and even in which time frame).
ciao
hannes
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf