Date: Thu, 30 Aug 2001 15:14:30 -0500
From: Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I gave myself 24 hours off from this thread to draw breath. Here are
| comments on a bunch of points from various people.
I have taken longer than that, while trying to figure out what is
really going on here.
I think I have a better understanding now, so here are some more
opinions, this time little less uninformed...
| My private opinion is that in the end the
| ISPs will need to settle down to using the recommended values across
| domain boundaries, but what they do in their bilats or within their
| domains is not something the IETF can dictate.
You keep saying this, in one form of words or other - and it is obviously
true. Nor would we want to. On the other hand, we can certainly constrain
the sensible options - we do that all the time with the protocols and
mechanisms we create. A lot of that seems invisible, it is just a part
of the flora that doesn't stand out, because it has all been there for so
long that people just accept it as a natural part of life, and not to
be worried about - accept it, and deal with it. But all kinds of things
have been invented by the IETF (and other groups - IEEE, ISO, etc) that
place all kinds of constraints upon what is sensible to agree, as do
politicians and lawyers (though their constraints tend to have different
kinds of effects if ignored).
To give some semi-relevant examples .. IEEE (and or DIX before them)
constrained ethernet frames to 1500(++) bytes: that constrains packet
sizes that are passing between ISPs. They may prefer larger ones (less
switching), and they might like to write agreements that demand larger
ones - but they don't, because that would be stupid, and everyone knows that.
Even closer to this discussion, the IPv4 and IPv6 headers have fixed sized
fields (different ones) into which this QoS information can be placed.
The IETF imposed those limits, there's no natural or legal restriction
that forced them. It was just a judgement call on how much space could be
afforded, and how best to divide that among competing uses. Again, the
ISPs (and in this case, diffserv WG) are just accepting those limits, and
dealing with them as best can be done. They might want to be able to have
64K different packet classifications, but they can't - there simply aren't
enough bits provided for that, so they make do with less.
We can do more of this if the arguments for imposing more constraints
are accepted by the relevant WG, and if we do, the ISPs will just need
to deal with those constraints in their agreements.
This is not specifying what the ISPs can agree with each other, which
we can't, and wouldn't anyway, do, just designing the protocols that
they happen to be agreeing with each other about...
| Yes, except that RFC 2460 does not describe this in normative text.
Part of this discussion is to whether or not anything about the flow label
should be fixed now for all time, or whether it should remain in its
current state (for a while at least).
My read on what I have seen here is that there isn't yet enough agreement
about what should go there that ipngwg should change the current status
of that field - just leave it exactly as it is.
I certainly don't consider it unthinkable for IPv6 to continue with a
bunch of more or less undefined bits - I don't consider very much at all
as unthinkable - doing that tends to bias your options way too much,
and lead to missing other viable solutions.
| 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.
This guessing based upon port numbers is simply absurd - and simply
leads to people doing weird machinations on port numbers because they
can predict what effects that will have upon the network in the middle.
That's not what port numbers were ever for.
It also doesn't work - many packet flows that should get special QoS
attention are between random port numbers at each end, totally unpredictable
until the after the rendezvous and connection has been established.
Should DNS SRV records start being used for more services, you'll see
even more of that - port number classification is a crock that simply
has to be abandoned.
What's more, it is absolutely no business of the ISPs what port numbers,
or for that matter, what transport protocol, I happen to be using to
communicate with my peers. That is entirely between me and them.
With ESP, and especially with IPv6, none of that information will be
available, and that's a good thing. Making it available again by
sticking the same information (even in a reduced form) in some unprotected
header is simply wrong.
On the other hand, if I want some special forwarding processes (QoS)
applied to my packets, I certainly have to be willing to provide that
information. Whether I calculate from port numbers, or just because
this particular web page is one I want real fast (even though it is the
same port number, same server, as that other web page I don't care
about nearly as much), is none of the ISPs business. Nor is it of
the IETFs.
For intserv, as I understand it, I do this using RSVP, I communicate
my needs, and indicate how the packets will be labelled so the routers
can properly process them (provided they're willing, I'm prepared to
pay if required, etc...)
For diffserv, there's no out of band signalling, so every packet needs
to be labelled so it can get the correct processing. That (as can
intserv as I understand it) be done with no mutable header bits at all.
The sender could simply provide a standard classification label, the
ISP could choose to process it or not (at every router, though one would
assume using a common distributed configuration). No need to rewrite
anything.
But because there are mutable bits, the decision is to use them to speed
processing at intermediate nodes - with only the border routers between
ISPs (or ISP/client) actually looking at the user's provided classification,
and everything between simply trusting the value (DSCP) set by the
border routers, and doing its packet processing based upon that value.
Had there been no mutable bits that would never have been possible, and
things would simply have to have been done the other way - it is of course
still possible to pretend the bits are immutable, and process them that
way (whatever the IPv6 protocol actually requires). But I see the
attraction for using them (one mutable bit "this value is to be trusted,
or not" and a value set by the sender would really be enough though).
| Indeed, I think this is a basic trade-off: to ask for QOS in the
| absence of both signalling and SLAs, you have to reveal something.
Yes, I have to reveal the QoS I want. No more, no less. There cannot
be an absence of signalling, I suspect you mean an absence of out of
band signalling - but that's largely irrelevant. I have to provide the
information somewhere, sometime, no question about that.
| Or to put it another way, if your level of paranoia prevents you
| from revealing a PHB ID, then you have three choices:
| a) accept default QOS
| b) use IntServ
| c) ensure that all ISPs on the path have the right kind of SLA
d) Adopt a QOS model that takes in-band defined signalling which carries
only the QoS desired. Nothing extra. That is all that is required.
There was something Alex said (I think) a couple of times, which I think I
agree with ... that is, the IPv6 basic header should contain only data
that is necessary to packet forwarding - this is the thing processed by
the fast path, and shouldn't be having other stuff thrown in there which
isn't related to that process.
That I think is what dooms the proposals to add PHB ID values into the
flow label - they're not needed for fast path processing, they only
get used at ingress/egress routers, where the header is (possibly)
going to be changed by rewriting the DSCP, and where it seems that
you're willing to poke into transport headers to find values of
interest. While it is possible in some cases to process all of this
quite quickly - it isn't the basic packet forwarding operations that
the IPv6 header should be supporting.
On the other hand, the flow identifier (micro-flow if you like), whether
it is being used for intserv, or just to allow routers to quickly find
the likely forwarding information (quick key to a CAM lookup) is most
definitely fast path material. It needs to be there for that, and it
needs to be optimised for that. That is, whether or not the packet might
also be passing through some diffserv domains, and getting diffserv
processing along part of the path.
So, if we are going to be moving the flow label definition anywhere into
the normative text, the definition I would be happy with at the minute is
exactly the one which currently exists.
Now, I can imagine you wondering ... "higher up he agreed that we
need to have QoS data available to diffserv, but now the only place to
put it has just been eliminated as a possibility - contradiction..."
Not at all, rather, false premise. The flow label isn't the only place
that diffserv QoS signalling can be placed. It is just where you have
currently decided is available to dump it. It is already clear that for
IPv4 there's no flow label available, so you're willing to go trolling
through transport headers to find the (inappropriate anyway, but never mind)
information you need. For IPv6 you could do the same, except that ESP
gets in the way (it will for IPv4 as well, in time), and the nature of
the header chains makes the transport headers harder to locate, so you'd
prefer not to have to do that.
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).
What's more, you can also have this header carry an independent QoS request
from the receiver (returned to the sender in an earlier reply packet) so that
ISPs with a relationship with the recipient of the packet can classify
it according to the receiver's view of how the packet ought be processed,
instead of the senders. If the receiver starts getting packets with
classifications it never authorised, it can just reset the connection,
and if that doesn't work to halt it - then it is just another DoS attack
to track and kill (since none of this data is authenticated, such attacks
will be a fact of life, however the classification is done).
Now to the header. The obvious clean way would be to define a new QoS
header type, and stick the data in there. That way it contains exactly
what is needed, and can be structured so as to be easy for hardware to
access the fields (it could even carry authentication information if
anyone believed that it would ever be actually used).
However, adding a new header requires (at least) the source and
destination to be able to handle that header, and requiring it to
be in this particular position also means it would need to be understood
by every router that might ever process a routing header.
If IPv6 were widely deployed, that would be unimplementable - but since it
isn't really yet, it is still feasible, though only barely I suspect.
The other way is simply to carry this in a destination options header,
and require that header to be immediately after hop by hop options (in
other contexts we have discussed the possibility of headers appearing
in "weird" orders, and I believe, agreed that support for that is needed).
Then, a QoS option can be defined (unknown options can be skipped, so
this is easier than a new header) to carry the necessary data. The format
wouldn't be as flexible, or nice, as a new QoS header, but it is easier
to get implemented (still have a possible problem with intermediate
routers, and routing headers, but there is much less of that to worry
about). The formatting can be made rigid - the QoS option could be
required to be the first option in this particular header, etc, so it
would still be easy for hardware to check for its presence, and extract
the values (the only variable, in either case, is whether a hop by hop
options header is present, and hardware needs to deal with that decision
already - if it is, probably the packet will be slow path shunted, if
it isn't, then the QoS data would be in a fixed position relative to the
IPv6 header - or not there at all).
Might something along these lines possibly satisfy everyone?
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
