Subject: RE: Higher level question about flow label

From: [email-masked]
Date: Thu, 30 Aug 2001 01:00:31 +0300

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 for the PHB in question. Therefore usage of the
recommended DSCPs intra-domain would seem to be sufficient.

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 label.

Also, mutability and standardized semantics would seem to be orthogonal
issues.

	Jarno

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 29. elokuuta 2001 1:01
> To: [email-masked]
> Cc: Steve Blake; [email-masked]
> 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:
> > 
> > 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 providers, because that was the only model that had a hope
> > > of being deployed.
> > But bi-lat's don't necessarily require mutability of the TC 
> field. That
> > was simply a concession to those who wanted knobs to make it more
> > difficult for the less skilled. Now we have a mechanism 
> that only has
> > a hope of being deployed, but is operationally useless on a global
> > scale because it lacks any context.
> 
> I think that is quite unproven. Specifically (apart from a 
> few researchers)
> the kind of thing I expect major ISPs to do with the flexibility is
> to implement multiple instances of the standard PHBs, which 
> requires them
> to use additional DSCP values for the multiple instances. The 
> context will
> be provided by a QOS policy management system and their SLAs.
> 
> > > The Diffserv flow-label proposal is trying to
> > > invent an end-to-end, in-band QoS "signaling" mechanism 
> to operate in
> > > parallel with the hop-by-hop DSCP "signaling".
> > Basically the hop-by-hop decisions have to be based on consistent
> > end-to-end semantics of a set of bits, but the TC field was allowed
> > to be randomized so it is currently useless for that purpose. This
> > is still fixable by locking down the PHBs and matching DSCPs, so
> 
> This is a dream. It isn't going to happen. I went through 
> denial/anger/acceptance on this three years ago.
> 
> > there is no need for taking additional header bits.
> 
> Abolish IPSEC and I will agree with you.
> 
> > 
> > > The only additional
> > > in-band information that would be remotely useful for 
> Diffserv would
> > > be a credit card account number.
> > Not if the proposed new end-to-end signaling is left as 
> mutable. There
> > will be a never-ending series of requests for bits until it 
> is accepted
> > that what is required is an end-to-end immutable set that the origin
> > node uses to identify its intent for the packets, (in or 
> out of band).
> 
> There is no request for a new mutable field. On the contrary, diffserv
> classification needs something that is globally unique.
> 
> > The intervening networks will always make local decisions based on
> > those bits, so there is no need to rewrite them at every 
> domain boundary.
> > All the TC field is used for now is an embedded MPLS type 
> tag, so why is
> > it embedded? 
> 
> That's a *complete* mischaracterisation. It doesn't resemble an MPLS
> tag in any shape or form. It's in the IP header becasue it is used to
> drive schedulers for queues of IP packets.
> 
> > Shouldn't it be the end-to-end consistent set of bits and
> > let MPLS do the tagging it will undoubtedly do for TE 
> purposes anyway?
> 
> MPLS is not the e2e protocol in the Internet, and is probably only
> a passing phase anyway. Diffserv traffic will get mapped onto 
> a variety
> of hardware layers; but diffserv is about IP packet 
> scheduling, not about
> lower layer frame scheduling.
> 
>   Brian
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 29 Aug 2001 16:17:27 -0700

> additional support from the flow label.

Thank you for making this point, because you have done it
better than I have been able to. If the DSCP is consistent
from end-to-end, each domain can make its own decisions.
I really don't care what they do with the bits in the middle,
as long as they exit the domain like they entered it. We don't
need to redefine the flow label if the diffserv WG will 
simply define a set of standard DSCP values for interdomain
use.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2001 15:52:08 -0500

> additional support from the flow label.

If you accept that ESP traffic will get QOS treatment only if there is
a suitable SLA at every domain boundary on its path. (Incidentally, the
same is true of intserv - if there is no SLA, there is no reason why
intserv would work across a domain boundary.)

> Also, mutability and standardized semantics would seem to be orthogonal

Yes, I think so. As I've been trying to communicate, there is nothing to stop
ISPs using the standardised DSCP values across domain boundaries today,
if they have an SLA in place. 

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2001 15:58:17 -0500

> simply define a set of standard DSCP values for interdomain

It's been done, by RFC 2474, 2597, and 2598 (soon to be revised, 
but the DSCP value doesn't change). What we can't do is force ISPs 
to use them. In particular, we can't force ISPs that don't support 
diffserv to use them. Like it or not, there *will* be scenarios
where an ISP can't rely on the arriving DSCP value.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 30 Aug 2001 15:48:58 -0700

Brian E Carpenter wrote:

> Like it or not, there *will* be scenarios

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 consistent. The reality is that the only way to 
reconstruct a meaning through the inconsistent SLA 
chain is to go back to the immutable bits.  

I have no problem with a strongly worded BCP
that says all DSCP values should be reset to a set of 
globally agreed values at exit. I understand that does
not force ISPs to abide, but at least it gives them 
some clue what to do, and the market will sort out the
ones that comply from the ones that can't deliver the
expected level of service.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2001 10:00:27 -0500

> expected level of service.

Believe it or not after all I've said, I agree with you
(personally, not speaking for the diffserv WG). But this is
an operational issue where we would need at least some
ISPs on board.

   Brian