Subject: RE: [PCN] RE: ECN & EF

From: <[email-masked]>
Date: Thu, 6 Sep 2007 18:28:27 +0100

Looking at the various comments in this thread, my proposal is to amend
the architecture draft so it says David's option b) below, and mention
Ruediger's "CBR-like" case - plus add (by way of explanation) a
reference back to Assumption 2 (real time appls generating inelastic
traffic). 

Ok?

Phil/

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: 29 August 2007 20:42
> To: [email-masked]
> Cc: Eardley,PL,Philip,CXR9 R; [email-masked]
> Subject: Re: [PCN] RE: ECN & EF
> 
> AF is proposed for video because video has variable traffic and one
> might want to mark frames of lower delivery importance with a higher
> drop probability. Think layered codecs and the difference between I
> frames and other types of frames. That said, I would be hard pressed
> to recommend it for voice unless the other characteristics were such
> that the math in RFC 3247 was supported.
> 
> What PHB one uses is all about what the characteristics of the
> intended applications are. I would be pretty hesitant to use PCN in
> an environment where you couldn't run an entire session and perhaps
> several in the margin zone - if suddenly adding 10% more sessions
> simultaneously when things are at the edge is going to disrupt
> existing sessions, the margins are too tight. For that reason, I
> think part of this discussion has got to be "for what application"
> and the testing has to include testing it with that application in
> live environments.
> 
> On Aug 29, 2007, at 12:20 PM, [email-masked] wrote:
> 
> > Phil,
> >
> > EF PHB has the right properties for this traffic, but it's not the
> > only way to get them.  I think the decision on the table is:
> > 	a) It has to be the EF PHB, vs.
> > 	b) It has to be similar to the EF PHB, but need not be
> >  		exactly the EF PHB.
> > For the latter, over-provisioned AF may be another way to do this.
> >
> > I don't have a strong opinion on which alternative we choose, but
> > one of them does have to be chosen.
> >
> > Thanks,
> > --David
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >> Sent: Wednesday, August 29, 2007 3:45 AM
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> Subject: [PCN] RE: ECN & EF
> >>
> >> Steven,
> >> Thanks - my perspective is in-line
> >> phil
> >>
> >>> -----Original Message-----
> >>> From: Steven Blake [mailto:[email-masked]]
> >>> Sent: 24 August 2007 23:06
> >>> To: Eardley,PL,Philip,CXR9 R
> >>> Cc: [email-masked]
> >>> Subject: ECN & EF
> >>>
> >>> [Chair hat off]
> >>>
> >>> Philip et. al.,
> >>>
> >>> I see that in Sec. 3.5 of the architecture draft, you assume:
> >>>
> >>> - Packets with ECN CE markings arriving at a PCN ingress router
> >>>   are automatically dropped.
> >>>
> >>> - EF PHB is assumed for all PCN-managed traffic.
> >>>
> >>> I asked previously if we needed to make the first
> >> assumption when ECN
> >>> header bits are NOT being used to signal PCN markings.  As
> >> far as I know
> >>> the answer is no.  So I would suggest you either (a) write up a
> >>> rationale for assuming this, or (b) mention that it is only an
issue
> >>> when re-using the ECN bits for PCN marking (which we haven't
decided
> >>> yet).
> >>
> >> Yes, I think your option b) is true. I'll modify this section
> >> to say this.
> >>
> >>>
> >>> Regarding the second assumption, it might or might not be a
sensible
> >>> idea in most circumstances, but I cannot think of a
> >> rationale as to why
> >>> it is required.  So I suggest that you also come up with a
> >> rationale for
> >>> this assumption, or weaken the statement in the draft.
> >>
> >> It's basically Assumption 2 (Section 3.2), "We assume that PCN-
> >> packets
> >> come from real time applications
> >>    generating inelastic traffic [Shenker] like voice and
> >> video requiring
> >>    low delay, jitter and packet loss, for example the Controlled
Load
> >>    Service, [RFC2211], and the Telephony service class, [RFC4594]."
> >>
> >> I don't think the EF PHB is intended to say anything
> >> different (is that
> >> true?), although you could argue they're not the same.
> >>
> >> The justification in S3.2 says: "This
> >>    assumption is to help focus the effort where it looks like
> >> PCN would
> >>    be most useful, ie the sorts of applications where per
> >> flow QoS is a
> >>    known requirement."
> >>
> >> this is true, although personally I think there's more to it
> >> than that -
> >> we don't really understand how the 'Many flows' assumption
> >> (Section 3.3)
> >> works for rate adaptive traffic. Compared with VBR traffic, rate
> >> adaptive tends to have much coarser changes of rate (bigger jumps,
> >> sticks at new rate for longer time), which probably makes it
> >> harder to
> >> get nicely behaving aggregated traffic. The other thing for rate
> >> adaptive traffic is to imagine if the PCN-domain is the part of the
> >> end-to-end path with the bandwidth constraint. One could imagine
> >> after
> >> flows had been admitted that the rates start adapting upwards.
There
> >> would be no pkt drops to trigger the sources to adapt their rates
> >> downwards, and so flow termination would eventually kick in.
> >> I think the
> >> safety margins you'd need to allow would be greater than for VBR
> >> sources. However, we haven't (as far as I know) investigated how
much
> >> harder rate adaptive sources would be for PCN than VBR ones
> >> (whether you
> >> just have to be more cautious and allow bigger safety margins, or
> >> whether it doesn't really work). Hence the assumption in S3.2.
> >>
> >> So my suggestion would be to keep the statement about EF PHB but
> >> add a
> >> reference to S3.2 and say something like "it isn't intended
> >> to be saying
> >> anything different to this"
> >>
> >> Comments?
> >>
> >>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >>> Steven Blake                <[email-masked]>
> >>> Ericsson/Redback Networks               +1 919-472-9913
> >>
> >>
> >>
> >> _______________________________________________
> >> PCN mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/pcn
> >>
> >>
> >
> >
> > _______________________________________________
> > PCN mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pcn

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