Subject: [PCN] **DRAFT** IETF 76 PCN meeting minutes

From: Steven Blake <[email-masked]>
Date: Thu, 12 Nov 2009 05:53:17 -0500

Howdy.

The draft meeting minutes from Tuesday are attached.  Thanks to Philip for
taking them!

Please send comments/corrections to the list within the next week.

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Nov 2009 16:02:49 +0100

Hi Steven

Thanks for sending the (draft) PCN meeting minutes!

Regarding the minutes over the signaling requirements draft and the 
CL and SM edge behaviour drafts I would like to have a discussion with 
Tom before commenting on the comments/conlcuison of the meeting.

Regarding the encoding comparison draft and the PCN HOSE edge behaviour
draft, 
I will provide comments in subsequent drafts.

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Steven Blake
> Sent: donderdag 12 november 2009 11:53
> To: [email-masked]
> Subject: [PCN] **DRAFT** IETF 76 PCN meeting minutes
> 
> Howdy.
> 
> The draft meeting minutes from Tuesday are attached.  Thanks 
> to Philip for taking them!
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Nov 2009 16:18:05 +0100

Hi Steven, Hi all

The PCN encoding comparison draft minutes and my comments on them, are
listed below!

> o Encoding Comparison
> draft-ietf-pcn-encoding-comparison-01
 > http://www.ietf.org/proceedings/09nov/slides/pcn-5.pdf

> Steven Blake presented the slides on behalf of Kwok Ho Chan, 
> who was not
> able to attend.  Thanks to Kwok for his work on it.  
> Steven polled the room to see how many had read the draft; few had.

> Lars Eggert: It got added to the charter - so the people who 
> wanted it added to charter are expected/obliged to review it.

> Steven Blake: Want to go to working group last call before the end of
year.

Georgios: I would like that too!

> Philip Eardley: I have 2 comments that I think need to be solved before it
is
> ready for LC:
> - It doesn't give a good sense of why baseline was chosen

Georgios: Phil, please provide more detailed comments on this, 
such that we can update the draft accordingly!

> - It doesn't give good sense of the pros & cons of various working-group 
> proposed extension encodings.

Georgios: Please note that the goal of the current PCN encoding comparison
draft is to present 
the decissions that have been made up to the time that the solution
described in the 
baseline encoding draft has been chosen. The current version of the draft
does not discuss the selection process
of other extended proposed extension encodings. 

Phil, do you think that it makes sense to also include information 
about the selection process of the other proposed extension encodings?

> Steven Blake asked for the status of draft-ietf-pcn-3-state-encoding and 
> draft-ietf-pcn-3-in-1-encoding. One of them (which?) is blocked due to a 
> dependency on the ECN tunneling draft.

> Bob Briscoe: ECN tunnelling draft-related encoding status - I think/hope
that I
> have resolved the blocking issues with David Black, so the draft should
soon be
> able to move forward.

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Nov 2009 16:32:58 +0100

Hi Steven, Hi all

The PCN HOSE edge behaviour draft minutes and my comments on them, are
listed below!

> o Hose Edge Behaviour
> draft-karagiannis-pcn-hose-edge-behaviour-00
> http://www.ietf.org/proceedings/09nov/slides/pcn-2.pdf

> Ronald in 't Velt presented slides on the HOSE edge behaviour.  The
marking 
> behaviour draft (draft-ietf-pcn-marking-behaviour-05) says that ETM-marked
> packets SHOULD be preferentially dropped - which is not what the HOSE edge
> behaviour wants.

> Lars Eggert: Can't update a standards-track document in an informational
edge
> behaviour document.

Georgios: Lars please note:
In Section 2.2 of
http://www.ietf.org/id/draft-ietf-pcn-marking-behaviour-05.txt is specified
that:

 o  PCN-packets that arrive at the PCN-node already excess-traffic-
      marked SHOULD be preferentially dropped;

In Appendix B4 is mentioned:

"The dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in
recognition that other dropping behaviour may be preferred in particular
circumstances, for example: (1) with the "marked flow" termination edge
behaviour, preferential dropping of unmarked packets may be better
[Menth09]; (2) tail dropping may make PCN-marking behaviour easier to
implement on current routers. Exactly what "preferentially dropped" means is
left to the implementation. It is also left to the implementation what to do
if there are no excess-traffic-marked PCN-packets available at a particular
instant."

The above emphasizes that in particular circummstances, preferential
dropping of unmarked packets should be possible. 
Such as circumstnace is specified in the HOSE edge behaviour draft.

> Philip Eardley: It seems dodgy to admit a flow if the signaling request is

> unmarked whatever the CLE.  This gives an incentive to send 1000s of
request
> repeatedly until one will get through.

Georgios: Phil, I do not understand the comment! Are you saying that QoS
signaling protocols, such as RSVP, 
cannot be used in such situations because no RSVP PATH messages will get
through? Please explain!

> Not many people have read the draft.

> Steven Blake: Need discussion on list before making this draft a working
group
> item, but the behaviour needs to work with the agreed marking behaviour
for
> ETM-marked packets.  I believe that it can probably can be made to work.

Georgios: I agree!

> Steven Blake: ECMP support - not safe to assume that path signaling
message
> will follow the same path as the data - so not safe to say that this
> scheme solves the ECMP support issue.

Georgios: Steve, please note that from the point of view of the followed 
communtication path for signaling messages and data packets, 
the same assumptions are used as the ones applied and used by RSVP PATH and
data packets.
Thus if the RSVP signaling works to support QOS, then the proposed ECMP
solution will also work.

> Francois le Faucher: Is it desirable that, in case the network is marking
50% 
> of packets, that we still accept 50% of new calls?

Georgios: Francois, I do not understand the comment, please elaborate!

> Steven Blake: Someone please send info to the mailing list.

> Bob Briscoe: Status update on the ECN tunnelling draft in tsvwg: thinks
issues
> have now been resolved, but thought this before.  Then 3-in-1 can go ahead
to
> last call, etc.

Best regards,
Georgios

---

From: Steven Blake <[email-masked]>
Date: Thu, 12 Nov 2009 19:57:05 -0500

On Thu, 12 Nov 2009 16:32:58 +0100, "Georgios Karagiannis"
<[email-masked]> wrote:

> message will follow the same path as the data - so not safe to say that
this
> data packets. Thus if the RSVP signaling works to support QOS, then the
proposed ECMP
> solution will also work.

Georgios,

I don't believe that is correct.  Can you comment Francois?

Regards,
 
// Steve

---

From: ken carlberg <[email-masked]>
Date: Fri, 13 Nov 2009 09:51:41 -0500

the answer is configuration and per-implementation dependent.  A number of implementations have a default setting of per-flow or per-destination form of ECMP, which is what would be needed for RSVP.  The danger arises if an in-path router is configured for per-packet ECMP -- some vendors/implementations support this, some don't.

-ken

On Nov 12, 2009, at 7:57 PM, Steven Blake wrote:

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

---

From: <[email-masked]>
Date: Sun, 15 Nov 2009 13:05:14 -0000

is

[phil] when you read the draft, you would be hard pushed to explain to someone else why the baseline encoding was selected. it would even take some effort to identify what the baseline was. 

[phil] the doc should explain what the idea of extensions to the baseline is, and why that idea was adopted.
 
[phil] i also think the doc should give a sense of the pros and cons of the various extension encodings that are still being pursued. i accept it needs some careful word-smithing in view of the fact that they have not been taken through WG last call etc.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 16 Nov 2009 10:36:28 +0100

Hi Ken

Thanks for the clarification! 
In my reasoning I have assumed that the default setting of ECMP is 
per-flow or per-destination form.

We could include this assumption in the HOSE edge behaviour draft!

Best regards,
Georgios

> From: ken carlberg [mailto:[email-masked]] 
> Sent: vrijdag 13 november 2009 15:52
> To: Steven Blake
> Cc: Georgios Karagiannis; [email-masked]
> Subject: Re: [PCN] Comments on HOSE edge behaviour discussion
> 
> the answer is configuration and per-implementation dependent. 
>  A number of implementations have a default setting of 
> per-flow or per-destination form of ECMP, which is what would 
> be needed for RSVP.  The danger arises if an in-path router 
> is configured for per-packet ECMP -- some 
> vendors/implementations support this, some don't.
> 
> -ken
> 
> 
> >> Georgios: Steve, please note that from the point of view of the 
> >> followed communtication path for signaling messages and 
> data packets, 
> >> the same assumptions are used as the ones applied and used by RSVP 
> >> PATH
> > and
> >> data packets. Thus if the RSVP signaling works to support 
> QOS, then 
> >> the
> > proposed ECMP
> >> solution will also work.
> > 
> > Georgios,
> >

---

From: ken carlberg <[email-masked]>
Date: Mon, 16 Nov 2009 06:28:21 -0500

Georgios,

Personally, I would be more cautious in the wording of your document regarding EMCP.  For instance, I wouldn't assume the per-flow or per-destination is the default case in all instances.  Instead, I would the more neutral stance and state that the these along with per-packet configurations exist, and that in order to use the Hose model, the per-flow/per-packet MUST be used.

-ken

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 16 Nov 2009 12:53:36 +0100

Hi Ken

Okay! Thanks!

Best regards,
Georgios

> Sent: maandag 16 november 2009 12:28
> To: Georgios Karagiannis
> Cc: 'Steven Blake'; [email-masked]
> Personally, I would be more cautious in the wording of your 
> document regarding EMCP.  For instance, I wouldn't assume the 
> per-flow or per-destination is the default case in all 
> instances.  Instead, I would the more neutral stance and 
> state that the these along with per-packet configurations 
> exist, and that in order to use the Hose model, the 
> per-flow/per-packet MUST be used.
> 
> -ken
> 
> 
> >> A number of implementations have a default setting of per-flow or 
> >> per-destination form of ECMP, which is what would be 
> needed for RSVP.  
> >> The danger arises if an in-path router is configured for 
> per-packet 
> >> ECMP -- some vendors/implementations support this, some don't.
> >> 
> >> -ken
> >> 
> >> 
> >>>> message will follow the same path as the data - so not 
> safe to say 
> >>>> that
> >>> this