Subject: Re: [PCN] EF-ADMIT & PCN DSCP(s)

From: Bob Briscoe <[email-masked]>
Date: Fri, 14 Mar 2008 15:45:54 +0000

Anna,

[Copying this to the PCN list.]

I'm assuming PCN marking is applied to all the inelastic classes as a 
PHB group without re-marking their DSCP. So VOICE-ADMIT would just be 
one of the DSCPs that PCN would be configured to apply to.

If the DSCP was already set to one of the inelastic classes the PCN 
ingress would preserve it (assuming appropriate authorisation for the 
flow). Otherwise, it would remark the DSCP to whichever of the (3) 
inelastic DSCPs was most appropriate. But the PCN domain would treat 
all three DSCPs the same - both for scheduling and for PCN marking.

However, this only works simply if we don't use a second DSCP for 
re-marking (the experimental encoding).

For the non-SM experiments, we'll have to use 3 local DSCPs to map 
the possible 3 inelastic DSCPs. If the expt is successful and 
operators want PCN, that makes the argument even stronger for fixing 
ECN tunnelling so we can use the two ECT codepoints separately rather 
than 2n DSCPs where n = 3.

For MPLS, DSCPs are effectively tunneled, so there's not a problem 
mapping all 3 DSCPs to one (EF-ADMIT) over the MPLS domains (except 
of course for the severe shortage of codepoints).

Bob

At 14:56 14/03/2008, Anna Charny (acharny) wrote:
>Bob,
>
>I suddenly got confused. I understand I think how using ED-Admit will
>work as long as we are using only one DSCP.  But if we remark ED-admit
>when we start using the second DSCP,  then in order to preserve the
>end-to-end semantics of EF-Admit we would need to restore the DSCP at
>the egress.
>
>If we then say that we can use PCN treatment for OTHER traffic classes
>- then how do we know at the egress when we do  and do not need to
>restore the EF-Admit marking?
>
>Or do I misunderstand what you are saying?
>
>Anna
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: Friday, March 14, 2008 10:16 AM
> > To: Fred Baker (fred)
> > Cc: Anna Charny (acharny); Toby MONCASTER; Phil EARDLEY;
> > [email-masked]; CHAN, Kwok Ho; Georgios Karagiannis
> > Subject: Re: EF-ADMIT & PCN DSCP(s)
> >
> > Fred,
> >
> > At 23:08 13/03/2008, Fred Baker wrote:
> > >-----BEGIN PGP SIGNED MESSAGE-----
> > >Hash: SHA1
> > >
> > >
> > >On Mar 13, 2008, at 6:38 PM, Bob Briscoe wrote:
> > >
> > >>But we can't say "Lower speed access links being the primary
> > >>consideration" when we have an e2e path that goes through the fast
> > >>middle too.
> > >
> > >Fine. So I'm offering to put text in that describes how to interact
> > >with the high speed middle.
> > >
> > >Here's the problem. If I am building an end to end
> > capability, it has
> > >to work through both ends *and* the high speed middle. RFC
> > 4594 and RFC
> > >5127 are complimentary here: RFC 4594 describes classes that can be
> > >used to avoid unfortunate traffic interactions in the low
> > speed access,
> > >and RFC 5127 tells how to combine those in the gigabit core without
> > >breaking that.
> > >
> > >You are asking me to break that by applying a single DSCP to
> > the whole
> > >lot, preventing me from separating video service from voice
> > service in
> > >the access, and by using a common service profile for both,
> > which per
> > >the considerations of RFC 4594 are known to differ from the
> > >application's perspective.
> >
> > No, re-read my post - I'm agreeing with you. I'm just writing
> > down the thought process I went through to get to where you
> > are. To, hopefully, help you write the draft in a way people
> > will better understand.
> >
> > My last para:
> > "So, I think this means PCN has to be a configurable marking
> > for more than just VOICE-ADMIT. It has to be applicable to
> > all 3 inelastic media-oriented service classes.
> > "
> >
> >
> > Bob
> >
> >
> > >I think that breaking the access to simplify things in the
> > core is very
> > >silly.
> > >-----BEGIN PGP SIGNATURE-----
> > >
> > >iD8DBQFH2bPebjEdbHIsm0MRAubmAKCXwxbkLfK53VcJHVWsQGBZQak2FgCg91Je
> > >Z2qOS2YJZcGSi3zh9bfJvUU=
> > >=c5CD
> > >-----END PGP SIGNATURE-----
> >
> > ______________________________________________________________
> > ______________
> > Bob Briscoe, <[email-masked]>      Networks Research
> > Centre, BT Research
> > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.
> > +44 1473 645196
> >
> >
> >

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 14 Mar 2008 12:09:24 -0400

Hi Bob, 

OK, so I think we are in agreement. It would not work to use the
EF-Admit if PCN is using 2 DSCPs.  But it would work for the solution
with 1 DSCP (and two encoding states).

When 1 DSCP is used for PCN, the end-to-end semantics of EF-Admit
remains independent of PCN.  However, on a "PCN domain hop",  PCN
treatment will be applied to EF-admit to make the admission decision.
And that seems perfectly OK.

It (PCN domain hop) also can make a termination decision though - does
this create any issue with the end-to-end semantics of EF-Admit?

Right?
Anna  

> Sent: Friday, March 14, 2008 11:46 AM
> To: Anna Charny (acharny)
> Cc: PCN IETF list; Fred Baker (fred)
> Subject: RE: EF-ADMIT & PCN DSCP(s)
> 
> Anna,
> 
> I'm assuming PCN marking is applied to all the inelastic 
> classes as a PHB group without re-marking their DSCP. So 
> VOICE-ADMIT would just be one of the DSCPs that PCN would be 
> configured to apply to.
> 
> If the DSCP was already set to one of the inelastic classes 
> the PCN ingress would preserve it (assuming appropriate 
> authorisation for the flow). Otherwise, it would remark the 
> DSCP to whichever of the (3) inelastic DSCPs was most 
> appropriate. But the PCN domain would treat all three DSCPs 
> the same - both for scheduling and for PCN marking.
> 
> However, this only works simply if we don't use a second DSCP 
> for re-marking (the experimental encoding).
> 
> For the non-SM experiments, we'll have to use 3 local DSCPs 
> to map the possible 3 inelastic DSCPs. If the expt is 
> successful and operators want PCN, that makes the argument 
> even stronger for fixing ECN tunnelling so we can use the two 
> ECT codepoints separately rather than 2n DSCPs where n = 3.
> 
> For MPLS, DSCPs are effectively tunneled, so there's not a 
> problem mapping all 3 DSCPs to one (EF-ADMIT) over the MPLS 
> domains (except of course for the severe shortage of codepoints).
> 
> 
> Bob
> 
> > > No, re-read my post - I'm agreeing with you. I'm just 
> writing down 
> > > the thought process I went through to get to where you are. To, 
> > > hopefully, help you write the draft in a way people will better 
> > > understand.
> > >
> > > My last para:
> > > "So, I think this means PCN has to be a configurable marking for 
> > > more than just VOICE-ADMIT. It has to be applicable to all 3 
> > > inelastic media-oriented service classes.
> > > "
> > >
> > >
> > > Bob
> > >
> > >

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Mar 2008 12:17:37 -0400

so we're back to using a DSCP to signal a mechanism instead of what  
it is intended to signal, which is a service class?

I thought we had agreed to use DSCPs for service classes, which might  
in turn use or not use the PCN mechanism?

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 14 Mar 2008 12:22:22 -0400

> From: Fred Baker (fred) 
> Sent: Friday, March 14, 2008 12:18 PM
> Cc: Bob Briscoe; PCN IETF list
> so we're back to using a DSCP to signal a mechanism instead 
> of what it is intended to signal, which is a service class?
> 
> I thought we had agreed to use DSCPs for service classes, 
> which might in turn use or not use the PCN mechanism?

I believe we are in violent agreement on the above.  I am assuming that
the DSCP is used to signal a service class of traffic (with the
semantics of EF-Admit as described). And that service class may or may
not use PCN mechanism. In particular, it may use it on some hops but not
on others.
This will work if PCN will not overwrite the DSCP value, which will be
the case with the current two-encoding-states proposal. 

Is there something in what I said that made you think I meant otherwise?

Anna 

> classes as a