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

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 29 Aug 2007 10:58:24 +0200

Phil,

my comment in line, marked [Rudi]

Regards,

Ruediger

> Steven wrote [Chair hat off]
> 
> Philip et. al.,

[snip]

> - EF PHB is assumed for all PCN-managed traffic.

[snip]
 
[This] > 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.

[Phil]
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. 

[Rudi]: We should mention that explicitely.

[Phil]
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.

[Rudi]
There've been "real time applications generating inelastic traffic", 
"EF" and here you discuss "VBR traffic" and "rate adaptive traffic". 
You don't mention PCN traffic which isn't using EF. Do you assume "VBR 
traffic" and "rate adaptive traffic" to use other PHBs than EF? 
We should write down the assumptions which seem to be there on the 
PCN traffic and its management. I can imagine
- Voice traffic to use other PHBs than EF.
- Broadcast and Unicast traffic with CBR like charactersitics to 
  use non-EF PHBs.
Both may be good candidates candidates for PCN. 

I further don't have trouble with VBR sources. If every single VBR 
source's rate is far below the rate of the aggregate of many VBR 
sources and these VBR sources are statistically independant, then 
PCN should be able to operate smoothely on such an aggregate, which 
probably exposes CBR like properties.

[Phil]
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