Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions

From: <[email-masked]>
Date: Fri, 3 Aug 2007 19:32:16 +0100

Joe, you've persuaded me that your approach is better. I suggest we add
text along the lines of your second Option (the first assumes a
particular mechanism /encoding is chosen). Ie add (probably to end of
Section 4):

If a packet that is part of a PCN-flow arrives at a PCN-ingress-node
with its CE (Congestion experienced) codepoint set, then we assume that
the PCN-ingress-node drops the packet.

There are lots of other possible behaviours that could be explored, but
this assumption has the merit I think of being simple and sound
(ECN-friendly) - and means we don't expend effort devising something
cleverer (at least until we've finished doing the initial pcn charter). 

Everyone happy - or at least not too unhappy?

phil

> -----Original Message-----
> From: Jozef Babiarz [mailto:[email-masked]]
> Sent: 27 July 2007 06:15
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions
> 
> See below.
> 
> Regards, Joe
> email:[email-masked]
> Telephone:613-763-6098
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: July 26, 2007 7:34 PM
> To: Babiarz, Jozef (CAR:0S03); [email-masked]
> Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions
> 
> joe
> sorry i explained it badly, let me have another go.
> The scenario i was thinking of is this. We have a source sending data
to
> a receiver. somewhere in the middle between the Sx & Rx is a
PCN-domain.
> The traffic being sent is treated as PCN-traffic inside the PCN-domain
> ie put into the PCN Diffserv class. However, between the Sx and
> PCN-domain the traffic is treated in a class that can be ECN-marked.
> When the traffic reaches the Rx, should any ECN-marking (that happened
> before the PCN-domain) be preserved.
> 
> [Joe] Two options, 1/ if the group decides to support the flow
> termination method proposed in 3sm draft and assuming we agree on PCN
> encoding where CE=flow terminate, than a CE marked packet can be
> interoperate as this flow needs to be terminate. The ingress lets the
> packet into as is and the egress open seeing flow termination (CE)
> market packet does the flow termination procedure.
> 2./ The PCN-ingress node open detecting CE market packet, drops the CE
> marked packet.
> Now I have a question for you, is the flow in question PCN-capable? If
> yes than this is a case where a PCN-capable flow hits an ECN-capable
> router and should be rate reduce. [joe end]
> 
> One possibility is that this is a scenario that we don't need to worry
> about. If it is one we need to think about, then there are two
> possibilities for how PCN WG could think about it:
> [Joe] I think we need to worry about. [joe end].
> 
> (1) when such traffic reaches the PCN-domain, then tunnel it across
the
> PCN-domain. this means that upon decapsulation at the egress any
ECN-CE
> marking (that was there when the pkt reached the ingress) is
preserved.
> 
> [Joe] Why do you want to preserve ECN-CE marking of packet that is
> PCN-capable? If the ECN-CE marked packet does not belong to
PCN-capable
> flow, that use a different DSCP and possible a service class within
the
> PCN-domain that also supports ECN traffic.
> My assumption is that the diffserv domain has at least two service
> classes, a PCN-cable service class and others service class(es) for
> non-PCN traffic.
> Tunnel would only be needed if there is only one service class and it
> was PCN-cable. I do not believe we are proposing this.[joe end]
> 
> (2) devise an encoding scheme for PCN that preserves the ECN-CE
marking.
> these are the two possibilities i was trying to lay out in my original
> email, ie
> (1) deal with the issue in the architecture doc by saying a tunnelling
> solution could be done to solve the problem
> (2) in the encoding-comparison doc, examine what the impact of this
> would be on PCN-encoding (to inform the eventual choice of encoding)
> [Joe] The encoding-comparison draft needs to discuss possible marking
> interaction between ECN and PCN and propose combination(s) that best
> meet guidelines in RFC 4774.
> I think in the architecture draft we need to talk about the issue,
> should look at RFC 4774 and see which case apply to PCN-domain.
> 
> Maybe, I'm missing something, but I do not think that we need to
tunnel
> ECN-marked traffic across PCN-domain. [joe end]
> 
> phil
> 
> 
> ________________________________
> 
> From: Jozef Babiarz [mailto:[email-masked]]
> Sent: Thu 26/07/2007 22:26
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions
> 
> 
> 
> Phil and all see below.
> 
> Regards, Joe
> email:[email-masked]
> Telephone:613-763-6098
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: July 26, 2007 4:35 PM
> To: [email-masked]
> Subject: [PCN] PCN & ECN-(congestion experienced) interactions
> 
> <trimmed>
> 
> >the second issue is about what happens if traffic arrives at the
> PCN-domain >(for the PCN traffic class) that is already marked with
> ECN's CE codepoint >(congestion experienced). ie the issue is how to
> handle traffic which for >some reason is using ECN (end-to-end) and
also
> using PCN admission control >(across the PCN-domain).  this could be
an
> issue for the pcn-architecture >draft, and also for the
> chan-pcn-encoding one. certainly it's an issue >that's got to be dealt
> with by at least one of these drafts.
> 
> [Joe] If a packet belonging to a PCN-capable flow arrives at the
> PCN-domain, the ECN field should not be touched. What ever the
encoding
> of the bits is it is forwarded that way. OK, I'm assuming that PCN can
> be end-to-end some day.
> However, if packet belonging to a flow that is not PCN-traffic arrives
> at the PCN-domain it gets forwarded using a different forwarding class
> (DSCP) than what is used for PCN traffic. The PCN-domain uses Diffserv
> to provide the differentiation. Only PCN traffic get's the PCN
> treatment.
> 
> 
> >bob says:
> 
> >>>Although this is perhaps too detailed for the architecture, I
suggest
> >that any need for ECN marking on the same path but outside the PCN
> [Joe] >domain(s) should be handled by tunnelling across the PCN
domain,
> with a >non-PCN DSCP in the inner header (that turns on the RFC3168
> meaning of its >ECN field) and a PCN DSCP in the outer.>>
> [Joe] I do not understand. I though that we state that we would use
> Diffserv. Why tunnel?
> 
> >one possibility is to deal with this now, with the wording along the
> lines >that bob suggests above added to the architecture draft.
> basically say that >a solution on these lines would solve the problem
> (there may be others but >we won't think about them).
> [Joe] We do not need to tunnel.
> 
> >another possibility is that the encoding comparison draft includes a
> look >at the implications of a pkt being able to be PCN-marked whilst
> preserving >its ECN-CE - ie the effect in terms of how the
PCN-encoding
> is done. we >could end up deciding that it was worthwhile, orthat it
> wasn't worthwhile. >In the latter case we would go back to bob's
> solution above.
> [Joe] Let's do it in the architecture draft. The marking draft should
be
> only a survey of viable marking options.
> 
> >do people feel able to make a decision now to go for the first
> possibility >(as bob suggests - I'd be OK with this too) or do we want
> discussion within >the encoding-comparisons draft?
> [Joe] We do not need to mix ECN marking behavior and PCN marking
> behavior. My assumption is that we where going to use Diffserv and DS
> codepoints to separate traffic that is PCN-capable from traffic that
is
> not PCN-capable.
> 
> >thanks, phil
> 
> 
> 
> 
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pcn
> 

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

---

From: "Lachlan Andrew" <[email-masked]>
Date: Fri, 3 Aug 2007 18:27:27 -0700

That sounds good, as long as the dropping behaviour isn't set in stone
and can be revised if/when someone does devise something cleverer.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

---

From: <[email-masked]>
Date: Mon, 6 Aug 2007 12:31:04 +0100

Perhaps we should say this explicitly. So the text would read: 

If a packet that is part of a PCN-flow arrives at a PCN-ingress-node
with its CE (Congestion experienced) codepoint set, then we assume that
the PCN-ingress-node drops the packet.
After its initial Charter is complete, the WG may decide to work on a
mechanism (such as through a signalling extension) that enables
ECN-marking to be carried transparently across the PCN-domain.

Ok?

phil

> From: Lachlan Andrew [mailto:[email-masked]]
> Sent: 04 August 2007 02:27
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PCN] PCN & ECN-(congestion experienced) interactions
>

---

From: "Lachlan Andrew" <[email-masked]>
Date: Mon, 6 Aug 2007 10:43:25 -0700

Sounds excellent.

Lachlan

---

From: Steven Blake <[email-masked]>
Date: Mon, 06 Aug 2007 16:37:14 -0400

> Everyone happy - or at least not too unhappy?

Philip,

Please correct me if I am wrong, but this is only an issue if PCN were
to choose to use the ECN bits for PCN marking, right?

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: <[email-masked]>
Date: Tue, 7 Aug 2007 08:24:30 +0100

Correct ( I think)

> From: Steven Blake [mailto:[email-masked]]
> Sent: 06 August 2007 21:37
> Cc: [email-masked]

---

From: Steven Blake <[email-masked]>
Date: Fri, 24 Aug 2007 18:05:40 -0400

[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).

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.

Regards,

---

From: <[email-masked]>
Date: Wed, 29 Aug 2007 08:44:33 +0100

Steven,  
Thanks - my perspective is in-line
phil

> Sent: 24 August 2007 23:06
> Subject: ECN & EF

Yes, I think your option b) is true. I'll modify this section to say
this.

> 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?

---

From: [email-masked]
Date: Wed, 29 Aug 2007 15:20:42 -0400

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

> Sent: Wednesday, August 29, 2007 3:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [PCN] RE: ECN & EF
> 
> Steven,  
> Yes, I think your option b) is true. I'll modify this section 
> to say this.
> 
> >

---

From: Fred Baker <[email-masked]>
Date: Wed, 29 Aug 2007 12:42:07 -0700

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.

---

From: ken carlberg <[email-masked]>
Date: Wed, 29 Aug 2007 15:57:22 -0400

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

one possibility would be for audio streams that use transport layer  
FEC, and to mark the FEC packets with lower drop probability since  
they are built to reconstruct other lost data packets.

-ken

> and the testing has to include testing it with that application in  

agreed, that would be nice to see.  And just a side comment, my  
understanding is that folks are thinking more in terms of changing  
conditions that suddenly add significantly more than 10%.

-ken