Francis,
Your idea has value. Unfortunately, it poses the same type of problem
for IPv6 fast processing as the 5-tuple classification, which makes it a
non-acceptable alternative to the flow label (field in the main header).
Regards,
Alex
Francis Dupont wrote:
>
> In your previous mail you w
In your previous mail you wrote:
Unfortunately I think the extension header mechanism is probably
too heavy as Francis says, but I want to think a bit longer about
that (and re-read kre's last message and some of Jarno's messages).
=> this is heavy but we can do more with this than
Unfortunately I think the extension header mechanism is probably
too heavy as Francis says, but I want to think a bit longer about
that (and re-read kre's last message and some of Jarno's messages).
Brian
Francis Dupont wrote:
>
> Tony, I am afraid that you are right. Diffserv seems to need
Tony, I am afraid that you are right. Diffserv seems to need
reclassification at some points in the backbone and 20 bits are
not enough to do the job... not speaking of the IPsec issue.
According to an old thread the extension header mechanism of IPv6
makes (re)classification at very high speed di
Tony Hain wrote:
>
> Brian E Carpenter wrote:
>
> > Like it or not, there *will* be scenarios
> > where an ISP can't rely on the arriving DSCP value.
>
> Which is my point in calling them random bits. You are
> correct that by maintining a chain of integrity in the
> interpretation, there is no
I am on the road, so apologies, if the formatting of this message is messed
up.
>Tony Hain wrote:
>>Alex Conta wrote:
>
>> To me it is simple: I see the IPv6 main header divided into functions
>> for forwarding,
>> and functions for QoS.
>
>You appear to have forgotten that the endpoints nee
Brian E Carpenter wrote:
> Like it or not, there *will* be scenarios
> where an ISP can't rely on the arriving DSCP value.
Which is my point in calling them random bits. You are
correct that by maintining a chain of integrity in the
interpretation, there is no real need for the bits to
be consis
Tony Hain wrote:
>
> Brian E Carpenter wrote:
>
> > > There is RFC2996 to fix this problem...
> >
> > That only works up to the first diffserv domain on the traffic path.
> > As the packets enters a 2nd, 3rd etc. diffserv domain, the problem
> > reappears. By the way, the absence of signalling i
[EMAIL PROTECTED] wrote:
...
> A PHB-ID in the flow label is NOT the semantics, but a pointer to the
> semantics. The actual semantics are found from the respective specification,
> and since all the possible (future) PHB-ID pointed semantics cannot be
> hard-coded into the router, they need to be
Tony Hain wrote:
>
> Jarno Rajahalme wrote:
>
> > I might be wrong, but it seems that unless there is a case
> > where a locally
> > used DSCP value for a PHB cannot be mapped back to a standardized, PHB
> > definition recommended DSCP value at the domain egress, there
> > is no need for
> > add
[EMAIL PROTECTED] wrote:
...
> > and mark the bits the way they wanted to
> > because they couldn't trust the origin not to lie.
>
> ...but I fail to understand why should want to do anything else than remark
> to best effort if they do not trust the previous operator.
Because the destination i
[EMAIL PROTECTED] wrote:
>
> Brian,
>
> In the scenario you provided (multiple instances of the standard PHBs, each
> mapped to separate DSCP value), the mapping is reversible: the egress router
> of that domain should be able to map back to the single instance of the
> recommended DSCP value fo
Jarno, this is recursing the DSCP model up to the (proposed)
flow label. I don't think it's necessary. On this point I
am in agreement with Tony.
Brian
[EMAIL PROTECTED] wrote:
>
> Steve Blake wrote:
> > RFC2475 was built on the assumption of bilateral agreements between
> > peering provider
Jarno Rajahalme wrote:
> ...but I fail to understand why should want to do anything
> else than remark
> to best effort if they do not trust the previous operator.
Because their customer may be the destination and the
SLA on that side says treat all protocol X traffic from
Y as high priority.
Tony Hain wrote:
> I agree completely, but that was my point about trust. The
> operators were telling the diffserv WG that they would
> refuse to deploy unless they had the ability to ignore what
> the origin said
This far I understand...
> and mark the bits the way they wanted to
> because t
Jarno Rajahalme wrote:
> I might be wrong, but it seems that unless there is a case
> where a locally
> used DSCP value for a PHB cannot be mapped back to a standardized, PHB
> definition recommended DSCP value at the domain egress, there
> is no need for
> additional support from the flow labe
Jarno Rajahalme wrote:
> If there would be no local mapping of the DSCP value,
> I don't see why it should not
> work over multiple domains.
I agree completely, but that was my point about trust. The
operators were telling the diffserv WG that they would
refuse to deploy unless they had the a
Brian
You're missing my point.
Yes, there are some silicon forwarders that can be
easily adapted to changes in the header fields --
assuming that those changes are within the range of
flexibility that was already placed in the silicon.
ASICs are less flexibile than FPGAs which are less
flexibl
Steve Blake wrote:
>
> Jarno Rajahalme wrote:
>
> > Steve Blake wrote:
> > > RFC2475 was built on the assumption of bilateral agreements between
> > > peering providers, because that was the only model that had a hope
> > > of being deployed.
> >
> > Has this changed? Would there be hope for no
e Blake; [EMAIL PROTECTED]
> Subject: Re: Higher level question about flow label
>
>
> Preamble: this is getting pretty far away from the core of the debate.
> I'd like the chairs to make some consensus calls, because
> we are going round in circles.
>
> Tony Hain wrote:
&g
Jarno Rajahalme wrote:
> Steve Blake wrote:
> > RFC2475 was built on the assumption of bilateral agreements between
> > peering providers, because that was the only model that had a hope
> > of being deployed.
>
> Has this changed? Would there be hope for non-locally-mappable DSCP
> deployment N
Tony Hain wrote:
>
> But the point is that no provider will understand or trust the
> DSCP as it is passed between domains, so BA classification will
> fail after the first provider, and it will even fail there if
> that provider doesn't trust the host to mark it correctly.
>
There is no ques
In hope of maybe clearing out some of the confusion:
Brian E Carpenter wrote:
> > I fail to understand how either would break if they simply intrepret the
> > flow label semantics as 'the source has identified this set of packtes
> > as related'. In either case there is an out-of-band mechansim t
Steve Blake wrote:
> RFC2475 was built on the assumption of bilateral agreements between
> peering providers, because that was the only model that had a hope
> of being deployed.
Has this changed? Would there be hope for non-locally-mappable DSCP
deployment NOW? I've understood the standardized v
Tony Hain wrote:
>
> Alex Conta wrote:
>
> > I strongly believe, and am not the only one, please see
> > earlier messages
> > in the thread, packet forwarding and QoS processing in line
> > cards on routers at wire
> > speed is too critical to afford the use of flow label in the network
> > la
Alex Conta wrote:
> I think you are talking about tunnel mode ESP, and Brian talks about
> transport
> mode ESP.
I am not mixing them. Diffserv only works within a single domain
when ESP is used, because in that context there is a hope that
the SPI carries enough context for the first hop pr
Brian E Carpenter writes:
> No, it's the whole point: the classifier at a domain ingress must
> choose an appropriate DSCP value to write into the TC field, and that
> *requires* the classifier to interpret the semantics of some set of
> fields in the packet header.
I don't think this is q
Alex Conta wrote:
> I asked for clarifications. You didn't respond.
> I am sorry, in their absence, I would repeat again, what
> I said based on what I understood you saying, and you were quite vague
> in that sentence:
I thought I did respond. The use of the bits would only appear to
be vag
Tony Hain wrote:
>
> Alex Conta wrote:
>
> In fact, diffserv can't get the job done across multiple domains in
> the presence of ESP. There simply are no visible bits with well-known
> semantics to base the decisions on. Allowing the DSCP to be mutable was
> explicitly the work of the diffserv
Tony Hain wrote:
>
> I did not mean to be inflammatory, I was just reacting to the statement
> by Alex about what we can afford to do at this point in time.
>
Tony,
I asked for clarifications. You didn't respond.
I am sorry, in their absence, I would repeat again, what
I said based on wha
Brian E Carpenter wrote:
> Preamble: this is getting pretty far away from the core of the debate.
Actually I thought the threads were very focused on the topic.
Do we need to redefine the FL field to allow diffserv to have an
immutable field with well-known end-to-end semantics, or not? Since
th
Brian E Carpenter wrote:
> > There is RFC2996 to fix this problem...
>
> That only works up to the first diffserv domain on the traffic path.
> As the packets enters a 2nd, 3rd etc. diffserv domain, the problem
> reappears. By the way, the absence of signalling is a virtue, not a
> problem, from
Alex Conta wrote:
> > and is finding that it can't get the job done without
> taking over another field
> > with imutable properties.
>
> It can get the job done, but less efficient than in IPv4, and that is
> not because
> work done by the Diffserv WG.
In fact, diffserv can't get the job don
Brian E Carpenter wrote:
> Please don't use this kind of language. As I just said on the other
> thread, diffserv reached consensus (in 1998) on a completely self-
> consistent model meeting the key requirements stated by ISPs.
I did not mean to be inflammatory, I was just reacting to the state
Preamble: this is getting pretty far away from the core of the debate.
I'd like the chairs to make some consensus calls, because
we are going round in circles.
Tony Hain wrote:
>
> Steve Blake wrote:
>
> > I agree with your conclusion, but I disagree with the assumptions
> > you are making abou
Tony Hain wrote:
>
> Brian,
>
> > But in the diffserv case, which is stateless (no signalling,
>
> There is RFC2996 to fix this problem...
That only works up to the first diffserv domain on the traffic path.
As the packets enters a 2nd, 3rd etc. diffserv domain, the problem
reappears. By the w
Tony Hain wrote:
>
> Alex Conta wrote:
>
> I am not trying to exclude diffserv, just make the point that
> diffserv already has a field to work with
The DSCP field and its numbering space is not sufficient for everything
that one may want
Diffserv for.
Diffserv has two types of classifiers, t
Tony,
...
> At this point what we can't afford is redefining a field simply
> because the diffserv WG refused to create a set of end-to-end
> consistent bits.
Please don't use this kind of language. As I just said on the other
thread, diffserv reached consensus (in 1998) on a completely self-
c
Tony Hain wrote:
> Steve Blake wrote:
>
> > I agree with your conclusion, but I disagree with the assumptions
> > you are making about diffserv (for the sake of argument, say).
> I assume you are talking about the WG not the protocol. :)
Actually, the opposite. :)
> > RFC2475 was built on th
Steve Blake wrote:
> I agree with your conclusion, but I disagree with the assumptions
> you are making about diffserv (for the sake of argument, say).
I assume you are talking about the WG not the protocol. :)
> RFC2475 was built on the assumption of bilateral agreements between
> peering prov
Tony Hain wrote:
> At this point what we can't afford is redefining a field simply
> because the diffserv WG refused to create a set of end-to-end
> consistent bits. It is no surprise that people are finding it
> difficult to build hardware that will make consistent decisions
> when all the
Brian,
> But in the diffserv case, which is stateless (no signalling,
There is RFC2996 to fix this problem...
> the only out-of-band mechanism that works is if the flow label has
> intrinsic semantics. The fact that the packet belongs to a class is
> useless information on its own; you need to
Alex Conta wrote:
> ... snip ... It is some of the Intserv
> supporters that try to keep Diffserv out (excluded).
I am not trying to exclude diffserv, just make the point that
diffserv already has a field to work with and is finding that
it can't get the job done without taking over another fie
Tony,
[lots deleted since I think the nub of our mutual misunderstanding is
in this bit]
> > Which QOS model? We have two, and they are different and require
> > different flow label semantics to work.
> >
> I fail to understand how either would break if they simply intrepret the
> flow label s
Understood. This is all fine as long as the ASIC or network
processor can use a common solution for per-flow and
per-traffic-class classification - in that case it doesn't
care what the bits in the flow label are (although the
software that configures the tables that drive the classifier
might car
Tony,
I answer, since you addressed this to me.
Tony Hain wrote:
>
> Alex Conta wrote:
>
> [...]
> While the original purpose of the proposal for the flow label may have
> been QoS, there is nothing restricting it to that usage.
>
I do not think that the Carpenter/Conta draft tries to exclu
Brian E Carpenter wrote:
>> ...
>> an end-to-end immutable field which may provide a hint to the routers
>> that the sequence of packets with this marking are related
>
> I have to disagree very strongly with this. The proposal on the table
> is much stronger, is directly based on the IETF's two
Alex,
>IPv6 has the flow label, and it has extension headers for more than just
>IPsec, which IPv4 has not.
>The flow label has a QoS purpose, which means precisely Intserv, and
>Diffserv.
There are other uses of flows (and possibly the flow label field) that have
nothing to do with QOS. It is
Tony,
Tony Hain wrote:
>
> Alex Conta wrote:
>
> > The flow label has a QoS purpose, which means precisely Intserv, and
> > Diffserv.
>
> While the original purpose of the proposal for the flow label may have
> been QoS, there is nothing restricting it to that usage. Brian's original
> note ta
Steve Blake wrote:
>
> > You're forcing the use of a subset of Diffserv on everybody.
> >
> > One MUST be able to use Diffserv with IPv6, at a not lesser extent than
> > Intserv with IPv6.
> >
> > This is even more so, when it does not cost anything, or much, as you
> > seemed to agree at one poi
Tony Hain wrote:
>
> [...]The
> only one that may care is the destination host,
could you please clarify/elaborate?
> so trying to invert
> the non-transitive relationship between the flow label and QoS models
> is simply wrong.
could you please clarify/elaborate?
> [...] while the fact
>
MF classifiers in the fast
> path (forwarding plane). The limiting factor is of course the speed of the
> CAM's.
>
> -- thomas
>
> -Original Message-
> From: Brian E Carpenter
> To: Kastenholz, Frank
> Cc: [EMAIL PROTECTED]
> Sent: 2001-08-25 00:10
&g
Alex Conta wrote:
> The flow label has a QoS purpose, which means precisely Intserv, and
> Diffserv.
While the original purpose of the proposal for the flow label may have
been QoS, there is nothing restricting it to that usage. Brian's original
note tainted this discussion by including intser
> You're forcing the use of a subset of Diffserv on everybody.
>
> One MUST be able to use Diffserv with IPv6, at a not lesser extent than
> Intserv with IPv6.
>
> This is even more so, when it does not cost anything, or much, as you
> seemed to agree at one point.
IPv6 supports Diffserv tod
Jarno,
[EMAIL PROTECTED] wrote:
>
> Christian,
>
> I still believe that "bits are bits". As you pointed out, there is no
> certainty that a packet to port 80 will carry HTTP. Therefore we should not
> pretend to know. Any classification based on this "make believe" is
> inherently flawed (IHO).
For sure you can't squeeze all the bits into 20, which is why
we went for the PHB ID option where no squeezing is required.
As for beating up on IPSEC... that would take a bigger guy than me :-)
Brian
Alex Conta wrote:
>
> Michael Thomas wrote:
> >
> > Brian E Carpenter writes:
> > > The i
Jarno,
The diffserv architectire is the *result* of that discussion, with ISP
engineers, at the beginning of the diffserv effort, most specifically
at the interim WG meeting in June 1998. Comments below...
[EMAIL PROTECTED] wrote:
>
> Brian,
>
> I think this is the make or break question for t
Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > The issue is that if the packet is classified prior to being
> > encrypted, what do you do if a downstream ISP declines to
> > believe the classification (DCSP value) and wishes to reclassify
> > the packet? The proposal is to put enou
Brian,
I think this is the make or break question for the whole current flow label
discussion:
Has the validity of the scenario you describe (MF-classification between
diffserv ISPs) been discussed somewhere?
Some specific questions:
(model: sender -> ... -> upstream ISP -> downstream ISP -> .
Brian E Carpenter writes:
> The issue is that if the packet is classified prior to being
> encrypted, what do you do if a downstream ISP declines to
> believe the classification (DCSP value) and wishes to reclassify
> the packet? The proposal is to put enough semantics in the flow
> label to
gt; the population of the flow-label tables/data ("control plane").
>
> Jarno
>
> > -Original Message-
> > From: ext Alex Conta [mailto:[EMAIL PROTECTED]]
> > Sent: 24. elokuuta 2001 0:46
> > To: Brian E Carpenter
> > Cc: Rajahalm
The issue is that if the packet is classified prior to being
encrypted, what do you do if a downstream ISP declines to
believe the classification (DCSP value) and wishes to reclassify
the packet? The proposal is to put enough semantics in the flow
label to allow some degree of classification.
> > -Original Message-
> > From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> > Sent: 22. elokuuta 2001 22:54
> > To: Rajahalme Jarno (NRC/Helsinki)
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Higher level question about flow label
> >
> >
>
kuuta 2001 0:46
> To: Brian E Carpenter
> Cc: Rajahalme Jarno (NRC/Helsinki); [EMAIL PROTECTED]
> Subject: Re: Higher level question about flow label
>
>
> Brian,
>
> You covered the essence, so, I will just expend a little on the use of
> MSB:
>
> The differentiatio
Huitema [mailto:[EMAIL PROTECTED]]
> Sent: 23. elokuuta 2001 3:49
> To: Brian E Carpenter
> Cc: ipng
> Subject: RE: Higher level question about flow label
>
>
> > On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > > I think the WG needs to decide onc
andom numbers without breaking anything.
> >
> > Jarno
> >
> > > -Original Message-
> > > From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> > > Sent: 21. elokuuta 2001 23:31
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL
Tim Chown wrote:
>
> On Tue, 21 Aug 2001, Alex Conta wrote:
>
> > at page 15, in the draft. "(c)" protects the value of the flow label, or
> > rather, its meaning, where it is relevant to protect it.
> >
> > That is because, the value in itself, alone, is not meaningful. It is
> > the meaning
builds up the
flow label.
-- thomas
>-Original Message-
>From: Steve Blake [mailto:[EMAIL PROTECTED]]
>Sent: den 23 augusti 2001 16:55
>To: Thomas Eklund
>Cc: ipng
>Subject: Re: Higher level question about flow label
>
>
>Thomas Eklund wrote:
>
>
>> I al
Thomas Eklund wrote:
> I also saw Steve Blakes comment that is not recommended to use TCP/UDP ports
> in the hash key for ECMP but the one of the biggest problem with the
> bundling is to send one TCP flow over different path since it might end up
> in packet re-ordering due the different delays
t header 0 pointer and if it is you must
process that header.
-- thomas
>-Original Message-
>From: Derek Fawcus [mailto:[EMAIL PROTECTED]]
>Sent: den 22 augusti 2001 19:47
>To: Brian E Carpenter; [EMAIL PROTECTED]
>Cc: ipng
>Subject: Re: Higher level question about flow
> On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > I think the WG needs to decide once and for all whether the flow
label
> is
> >a) a CATNIP or MPLS-like routing handle
> > or b) a QOS hint for intserv only
> > or c) a QOS hint for intserv and diffserv
> > or d) a waste
Derek Fawcus wrote:
> Specifically - I see it as a way of replacing the srcPort/dstPort tuple
> that routers peek at in the TCP/UDP header. Currently I only see this
> being used in one scenario, that is for load balancing across multiple
> paths.
>
> At the moment (for v4) if a lookup on the
On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> I think the WG needs to decide once and for all whether the flow label is
>a) a CATNIP or MPLS-like routing handle
> or b) a QOS hint for intserv only
> or c) a QOS hint for intserv and diffserv
> or d) a waste of bits
>
>
Bill Sommerfeld writes:
> > > It seems that it would be appropriate for an implementation to
> > > "reclassify" packets at the time of encapsulation into ESP -- the
> > > packet is, after all, going through a logical trust boundary as it's
> > > being encrypted..
> >
> >If I underst
> > It seems that it would be appropriate for an implementation to
> > "reclassify" packets at the time of encapsulation into ESP -- the
> > packet is, after all, going through a logical trust boundary as it's
> > being encrypted..
>
>If I understand Brian's concern correctly, that may
>
> Oh. I now see what I missed. Why doesn't including
> the SPI into the flow key work? You wouldn't be
> able to police based on port numbers (ie try to be
> a firewall), but some would say that's a feature
> not a bug.
Well, except that there's no such thing as a "well known SPI"..
When done co
Bill Sommerfeld writes:
> >Huh? I thought that one of the requirements for ESP was to
> >copy the DSCP to the outer header. If I recall correctly,
> >this bothers some people from a traffic analysis standpoint,
> >but that seems to be part and parcel with QoS so that doesn't
>
>Huh? I thought that one of the requirements for ESP was to
>copy the DSCP to the outer header. If I recall correctly,
>this bothers some people from a traffic analysis standpoint,
>but that seems to be part and parcel with QoS so that doesn't
>hold much water IMO.
It seems th
t; To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [EMAIL PROTECTED]
> Subject: Re: Higher level question about flow label
>
>
> I certainly don't care about the pseudo-random requirement
> for unique-per-host
> opaque flow labels, but if we agree that the flow label may
> be used
Derek Fawcus wrote:
>
> On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > I think the WG needs to decide once and for all whether the flow label is
> >a) a CATNIP or MPLS-like routing handle
> > or b) a QOS hint for intserv only
> > or c) a QOS hint for intserv and diffse
Derek Fawcus wrote:
>
> > 2) If there is an alternative format, that is not pseudo-random (as
being
> > proposed), the routers will have to implement look-ups that function
> > efficiently with that format. Since we do not know what portion of the
> > traffic in the future would use this non-pseu
--
> > From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> > Sent: 21. elokuuta 2001 23:31
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subj
Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > The point is that when a packet crosses an administrative domain boundary,
> > the downstream ISP typically wants to reclassify the packet all over again,
> > i.e. does not accept the incoming DSCP as definitive. This was a very
> > clea
On Tue, 21 Aug 2001, Jim Bound wrote:
> the traffic class will provide diff serv metric and the flow identifies
> the E2E connection with the src addr.
My intuitive feeling is that if we leverage the end to end properties of
IPv6 in the address space, then we should do likewise, end to end, for
On Tue, 21 Aug 2001, Alex Conta wrote:
> at page 15, in the draft. "(c)" protects the value of the flow label, or
> rather, its meaning, where it is relevant to protect it.
>
> That is because, the value in itself, alone, is not meaningful. It is
> the meaning of the value, which is important,
ROTECTED]]
> Sent: 21. elokuuta 2001 23:31
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: Higher level question about flow label
>
>
> Jarno,
>
&g
Jim Bound wrote:
>
> Alex,
>
> > Jim,
> > [...]
> > I am afraid, there is a misunderstanding. Nobody advocated
> > transport+port to promote routing or as a strategy.
> > [...]
> > As I do not expect everyone to understand or care about bit shifting, I
> > should mention just for the sake of t
In my view, we didn't restrict it to be "non-mutable", but that is in
the boundaries set by:
" (c) A flow label is assigned to a flow by the flow's source node.
It
can be changed en-route, with the condition that its original
significance be maintained, or restored, when neces
Brian E Carpenter writes:
> The point is that when a packet crosses an administrative domain boundary,
> the downstream ISP typically wants to reclassify the packet all over again,
> i.e. does not accept the incoming DSCP as definitive. This was a very
> clearly stated ISP requirement at the
Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > The point is that when a packet crosses an administrative domain boundary,
> > the downstream ISP typically wants to reclassify the packet all over again,
> > i.e. does not accept the incoming DSCP as definitive. This was a very
> > clea
Brian E Carpenter writes:
> The point is that when a packet crosses an administrative domain boundary,
> the downstream ISP typically wants to reclassify the packet all over again,
> i.e. does not accept the incoming DSCP as definitive. This was a very
> clearly stated ISP requirement at the
The point is that when a packet crosses an administrative domain boundary,
the downstream ISP typically wants to reclassify the packet all over again,
i.e. does not accept the incoming DSCP as definitive. This was a very
clearly stated ISP requirement at the start of diffserv and is fundamental
i
Steve Blake wrote:
>
> Brian Carpenter wrote:
>
> > Thomas Narten wrote:
> > ...
> > > In my view, deciding on the right useage of the bits requires first
> > > understanding the problem that needs to be solved.
> >
> > I think that from the QOS viewpoint, we do understand the problem very well,
Brian E Carpenter writes:
> Thomas,
>
> The diffserv issue is that diffserv currently cannot properly classify packets
> that are hidden by ESP headers. If it wasn't for that, I personally wouldn't
> have gone near the flow label.
Huh? I thought that one of the requirements for ESP was t
Brian Carpenter wrote:
> Thomas Narten wrote:
> ...
> > In my view, deciding on the right useage of the bits requires first
> > understanding the problem that needs to be solved.
>
> I think that from the QOS viewpoint, we do understand the problem very well,
> hence the proposal to add a diffs
Hmm... it seems to me that both the formats we are suggesting (pseudo-random
and diffserv PHB ID) are immutable.
Brian
Alex Conta wrote:
>
> Jim,
>
> Please reexamine.
>
> As a hint, note that MPLS, which is using *mutable* labels, is using
> RSVP-TE (extension of RSVP
> for Traffic Engine
t would be
> faster to decode.
>
> Jarno
>
> > -Original Message-
> > From: ext Jim Bound [mailto:[EMAIL PROTECTED]]
> > Sent: 21. elokuuta 2001 15:58
> > To: Thomas Eklund
> > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob Hinden; ipng
Thomas Narten wrote:
...
> In my view, deciding on the right useage of the bits requires first
> understanding the problem that needs to be solved.
I think that from the QOS viewpoint, we do understand the problem very well,
hence the proposal to add a diffserv usage to the existing intserv usag
Original Message-
> From: Brian E Carpenter
> To: Thomas Eklund
> Cc: 'Francis Dupont '; 'ipng '
> Sent: 2001-08-19 21:30
> Subject: Re: Higher level question about flow label
>
> Thomas,
>
> How can you combine a routing handle usage with in
;Alex Conta'; Thomas Narten; Brian E Carpenter; Bob Hinden; ipng
> Subject: RE: Higher level question about flow label
>
>
> thomas,
>
> that is why if we can treat the flowlabel as part of tuple with src
> address and identify a connection which identifies the forwardi
1 - 100 of 136 matches
Mail list logo
