In your previous mail you wrote:
| It's the former; if an ISP chooses to disbelieve the upstream ISP,
| and re-classify the traffic, the semantics of the transport
| header are exactly the information of interest.
No they're not. There is nothing at all in any transport header of
relevance that contains anything in any way related to QoS.
=> I agree, the whole stuff about MF re-classification on
the 5/6 tuple seems silly to me.
For diffserv, there's no out of band signalling, so every packet needs
to be labelled so it can get the correct processing.
=> so even if MF re-classification on the 5/6 tuple is the wrong
problem we still have to investigate (:-).
But IPv6 has another way - you can simply request that the sender add
a new header (more on that in a second), require it to appear immediately
after the hop-by-hop options (if any, or the IPv6 header otherwise) for
it to be effective anyway (ie: you look that far, and assume default
processing if the header doesn't appear there). In this header you can
stick all the QoS classification information you're ever going to need.
That can even look like a transport protocol port number combination if
you like - just don't expect the port numbers (or even transport protocol)
to have any relationship at all with the ones the transport protocol or
its ports that are actually being used. I'll pick values that generate
the QoS effects that I desire (which might sometimes be a 1::1 mapping
from the value actually being used, but also might not be).
=> this solution was suggested in the last discussion about how to
do MF classification on the 5/6 tuple at very high speed (I believe this
discussion was initiated by Thomas Eklund). My only concern is simple:
is it a solution for the wrong problem?
Regards
[EMAIL PROTECTED]
PS: I sent my mail to Brian before reading your mail... The PHB ID
proposal can (should?) give better options than to put fake protocol/ports
into the QoS option for silly MF classifiers. If the overhead of
the QoS option is acceptable we should have to design smart way
to use it.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
