Subject: [PCN] Volunteer scribes needed

From: <[email-masked]>
Date: Sun, 26 Jul 2009 10:57:06 -0400

Please volunteer to take minutes or Jabber notes for tomorrow's meeting.

Thanks,

// Steve

---

From: <[email-masked]>
Date: Mon, 27 Jul 2009 10:43:05 +0100

In a perfect world this would be a nice document to have, so I'm in favour of it if it can realistically get done. 

However, i wanted to raise the question of how realistic this is? i think there is a lot of work to do on it (for example: the text was written before we realised the tunnelling issue, so the rationale for the baseline encoding isn't covered; the text was written before agreement on the various exptl encodings). Also, the reasoning behind the baseline is well covered in the baseline, and the extensions could include similar text explaining their rationale (by implication this covers the reasons for rejecting a lot of the other possible encodings). 

I agree ideally it would be nice to collect all this reasoning into a single document, but the question is whether this is the best use of the WG effort? after all, nothing has happened to this draft since the last ietf. So my suggestion would be to ask Lars whether it's ok to drop it, and to make sure that any exptl encoding going forward to rfc includes reasons for the choice of encoding.

phil

---

From: <[email-masked]>
Date: Mon, 27 Jul 2009 11:50:58 +0100

The essential thing is to make sure that we leave enough information for
posterity to ensure that future WGs don't end up wasting effort on as
many dead-ends as we did as a WG. This task is significantly simplified
for us because Bob's ECN tunnelling draft explains why there are
tunnelling limitations and reduces those limitations to a manageable
subset. So if Bob's draft becomes RFC then (in combination with the
baseline encoding and some slight additional text in extension
documents) all the relevant info is probably recorded.

If any of that made any sense...

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 27 July 2009 10:43
> To: [email-masked]
> Subject: [PCN] comment on draft-ietf-pcn-encoding-comparison
> 
> In a perfect world this would be a nice document to have, so I'm in
> favour of it if it can realistically get done.
> 
> 
> 
> However, i wanted to raise the question of how realistic this is? i
> think there is a lot of work to do on it (for example: the text was
> written before we realised the tunnelling issue, so the rationale for
> the baseline encoding isn't covered; the text was written before
> agreement on the various exptl encodings). Also, the reasoning behind
> the baseline is well covered in the baseline, and the extensions could
> include similar text explaining their rationale (by implication this
> covers the reasons for rejecting a lot of the other possible
> encodings).
> 
> 
> 
> I agree ideally it would be nice to collect all this reasoning into a
> single document, but the question is whether this is the best use of
> the WG effort? after all, nothing has happened to this draft since the
> last ietf. So my suggestion would be to ask Lars whether it's ok to
> drop it, and to make sure that any exptl encoding going forward to rfc
> includes reasons for the choice of encoding.
> 
> 
> 
> phil
> 
> 
> 
> 
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Mon, 27 Jul 2009 13:36:05 +0100

Comments on draft-ietf-pcn-cl-edge-behaviour 

Most of these also apply to the draft-ietf-pcn-sm-edge-behaviour draft

S1

"pcn uses dscp values" - could add 'in part'

Could add ref to encoding drafts

S1.1

PDP definition

This would be clarified by saying whether we assume it's at ingress or elsewhere (will draft cover both cases?)

S3.1

"Flow termination may be spread out over a period of time to avoid over-termination"

Dasiuke's results show that you need to do two things:-

-          if you do a second round of termination, wait for the longest RTT of the PCN-domain before you do a second lot of termination, otherwise there is over-termination. RTT means the reaction time - how long after the overload on a link before the load is reduced on the link. The reason is that otherwise IEAs with short RTT don't take account of the fact the other IEAs (with long RTT) are in the process of terminating some flows

-          when measuring the sustainable rate, measure it over a short period of time. Reason: otherwise measurement of sustanible-rate could be too high, because part way through your measurement there's some termination on IEAs with a short RTT

so some advice could be added on these lines, if we think these effects likely in practice (rather than things that are only significant in unlikely scenarios]

"[when alerted] the PCN-ingress-node similarly performs measurements to determine the rate at which it is admitting PCN-traffic..."

One option is for the ingress node to make this measurement continuously, ie so the result is already known if needed - thus speeding up the termination process. would it be any significant work to measure this continuously?

"the pcn egress node supplies a list of excess-traffic-marked flows" - this isn't compulsory. It's only useful if the pcn-domain is doing ecmp.

3.2.1 the egress measures the CLE over a fixed period. Does this period need to be the same over whole pcn-domain? [not sure]

3.2.1 new_CLE = k*R + (1-k)*old_CLE

I dont really see the gain of this. I think the draft should just measure the CLE over one measurement period. But it should have a statement that the operator might want to implement something beyond this as a local optimisation. So you could do what you suggest or indeed do a packet by packet EWMA (as in the old Briscoe-cl draft)

"in the absence of one of these two threshold crossing events the egress issues no report" - this assumes the centralised PDP case, not true for the rsvp etc case. I also assume that you'd also report periodically (to confirm still in admit state etc and not crashed) - it also sets a reliability requirement on the signalling

threshold-crossing is reported - this assumes centralised PDP, not true for on-path signlling (where piggyback on return RSVP msg say

I'd also add a recommendation that if there's no traffic currently on the IEA, then (1) in the rsvp-style case, then look to see if the rsvp request msg is pcn-marked (admit if it isn't); (2) in the centralised case, then admit the new flow

3.2.2 & 3.3.2

The admission and termination are tied together in several ways. I don't think this is a good idea. An operator may want to implement just admission or just termination, and this should be easy. Also, from a technical point of view I don't see why measurement of sustainable-rate and CLE should be over same measurement period.

The only link is that when you're doing termination on an IEA then you shouldn't admit into that IEA

3.3.2

"when the pcn egress node detects an excess marked pkt, it transitions to the excess traffic regime" - I'm not sure transiting when you see a single marked pkt is best - perhaps you should wait to see more than one. Also, if the operator knows that the network is using some lower layer protection mechanism (eg switch in a new optical path), then you may want to wait to give a chance for this mechanism to solve the problem before you terminate any traffic. I think exactly when you transit can be an implementation optimisation.

Should the egress report the CLE or should it report 'admit' or 'block'?

I don't see a whole lot of difference. It's 8 bits versus 1 bit. There's a slight advantage to reporting the CLE, in that there might be policy to admit some flows ("important") if CLE is below one threshold and some flows ("normal") only if CLE is below a lower threshold. [such policy won't be known at the egress]

In the on-path signalling case, then you don't have to signal CLE, you could just use the existing RSVP msg (ie it just gets rejected if CLE is too high)

S5 Security

"No new security considerations" - Prevent a false termination msg would be one security consideration?

S7 Acks

"appendices" are referred to, but don't exist?

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 29 Jul 2009 16:24:16 +0000

Hi Phil

Please see in line!

>In a perfect world this would be a nice document to have, so I'm in favour of it if it can realistically get done.

Georgios: I think that it can be done! my proposal is to provide the
survey and comparison that have been done until the baseline encoding
scheme has been chosen. I do not think that we need to include
comparisons that are related to choices on the upcoming encoding
proposals. This will actually satisfy the charter item and at the same
time the draft can be completely very soon. Kwok and I are willing to
spend time on completing this draft.

>However, i wanted to raise the question of how realistic this is? i think there is a lot of work to do on it (for example: the text was written before we realised the tunnelling issue, so the ration…

Georgios: We should focus on the survey and comparison that was needed to
select the baseline encoding document. This is already included in the
curent version of the draft. if his goal is followed then we just need
to do some refinements and editorials before completing the draft.

>I agree ideally it would be nice to collect all this reasoning into a single document, but the question is whether this is the best use of the WG effort? after all, nothing has happened to this draf…

Georgios: Please see my comments above!

best regards,
Georgios

---

From: Michael Menth <[email-masked]>
Date: Thu, 30 Jul 2009 00:45:04 +0200

Hi all,

> threshold-crossing is reported - this assumes centralised PDP, not true for on-path signlling (where piggyback on return RSVP msg say
This piggybacking is not very clean: a property of the IEA is reported 
in a packet belonging to one of its subflows. It's a hack and I do not 
see its value. Is it to save bandwidth or the definition of an extra 
signalling protocol? The RSVP process needs to be modified to handle 
such information correctly, right?

> I'd also add a recommendation that if there's no traffic currently on the IEA, then (1) in the rsvp-style case, then look to see if the rsvp request msg is pcn-marked (admit if it isn't); (2) in th…
Hm, if this is acceptable, we have almost lightweight probing as needed 
for PSDM. But don't we need to change RSVP then? Indeed, probing solves 
the problem of empty IEAs.

True. I also had this feeling.

> I don't see a whole lot of difference. It's 8 bits versus 1 bit. There's a slight advantage to reporting the CLE, in that there might be policy to admit some flows ("important") if CLE is below one…
When using only admit/block there is more "optimization potential" at 
the egress regarding when to admit/block. For instance, 
observation-based AC can be implemented which does not need to wait 
until the end of a measurement interval.

> "appendices" are referred to, but don't exist?
Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Thu, 30 Jul 2009 12:28:51 +0100

________________________________

From: Georgios Karagiannis [mailto:[email-masked]]
Sent: Wed 29/07/2009 17:24
To: Eardley,PL,Philip,DER3 R; [email-masked]
Subject: Re: [PCN] comment on draft-ietf-pcn-encoding-comparison

Hi Phil

Please see in line!

[phil] that doesnt work. quite a few of the words and reasoning in the draft is wrong, ie we learnt more since this draft was written quite some time ago.
the reason for selecting the baseline encoding isnt fully mentioned in this draft [the tunnelling issue was realised subsequently] but  is covered in the baseline doc. the reasoning is simple & short:-
- only one dscp [to save dscps]
- non-pcn traffic can go in same sdcp [ditto]
- cope with ecn tunnel egress re-setting non-11 codepoint 

phil

best regards,
Georgios