Subject: [PCN] A couple of proposed technical changes and one correction in the edge behaviour drafts

From: Tom Taylor <[email-masked]>
Date: Fri, 10 Dec 2010 16:29:34 -0500

I'm currently in the process of ensuring that the CL and SM documents 
use identical text except where necessary, and I'm flagging all the 
variant parts with [CL-specific] or [SM-specific] in their respective 
documents. I have been thinking about David's comments as I worked, and 
have come up with the following changes I would like to propose:

1. In the core network assumptions section for CL, remove the reference 
to a coding extension document and [I-D.3in1]. Say simply that 
excess-traffic-marking uses the EXP codepoint defined in RFC 5696.

The reason for this proposal is that as I understand RFC 5696, the 
implementation of all the codepoints is clearly defined in terms of ECN 
bits. What is not defined is whether and how the PCN-domain supports 
end-to-end ECN. I'm not sure the edge behaviour drafts need to discuss 
that. If they do, the discussion probably belongs in the PDB template.

2. Thinking about the timer settings for reliable and unreliable 
transport, I realized that we are unlikely to offer the operator a 
choice between the two. Instead, we will write our signalling 
requirements document and another WG (according to the charter) will 
specify the actual transport.

The implication is that the SM and CL drafts should state that the 
transport protocol has not been specified, and make it a requirement 
that when it is specified, the specifications must include default 
values for T-maxsuppress and T-fail.

3. In addition, I noted an error in the current SM draft. The value of 
the factor U has to be greater than 1, not less than 1. I should 
probably also mention that it represents an average ratio of 
PCN-supportable-rate to PCN-admissible-rate over all the links of the 
PCN-domain.

Comments, please.
Tom Taylor

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 10 Dec 2010 22:13:05 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Taylor
> Sent: 10 December 2010 21:30
> To: pcn
> Subject: [PCN] A couple of proposed technical changes and one
> correction in the edge behaviour drafts
> 

Seems sensible... Not sure if you need draw attention to the rules for using
that codepoint (section 5 of 5696)

> that. If they do, the discussion probably belongs in the PDB template.

I think it was generally agreed that, unless you use a really complex
encoding, PCN overrides e2e ECN. The only encoding that gives any ECN
support is the 3-state proposal, and that is only limited. Consequently I
don't feel you need make any mention of ECN in your documents.

> values for T-maxsuppress and T-fail.

Probably OK. Although it does give people yet more cross references they
have to check. The other way to do it is "typically t-maxsuppress and t-fail
have the following values, but these depend on the transport. If a transport
has significantly different requirements that should be specified in the
appropriate document" 

> PCN-supportable-rate to PCN-admissible-rate over all the links of the

That explanation would make it clearer, and it gives some idea of the likely
range for U...

Toby

PS Before we get too far down the road it would be sensible to check whether
Dave Harrington is satisfied or not. You have already spent a lot of effort
trying to merge the documents only to run into problems. I wouldn't like you
to have to go through another complete round of revisions only to be told to
start again!

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

---

From: Michael Menth <[email-masked]>
Date: Sat, 11 Dec 2010 13:31:43 +0100

Hi Tom,

Am 10.12.2010 22:29, schrieb Tom Taylor:
> documents. I have been thinking about David's comments as I worked, 
> and have come up with the following changes I would like to propose:
>
> 1. In the core network assumptions section for CL, remove the 
> reference to a coding extension document and [I-D.3in1]. Say simply 
> that excess-traffic-marking uses the EXP codepoint defined in RFC 5696.
>
> implementation of all the codepoints is clearly defined in terms of 
> ECN bits. What is not defined is whether and how the PCN-domain 
> supports end-to-end ECN. I'm not sure the edge behaviour drafts need 
> to discuss that. If they do, the discussion probably belongs in the 
> PDB template.
>
The value U (>1) actually defines the ratio between PCN-supportable and 
PCN-admissible rate. But this aspect is so far not really covered in the 
draft, I believe. To let the user know the impact of the parameter U, 
this relation would be indeed useful to know.

Best wishes,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Wilhelm-Schickard-Institute
Lehrstuhl für Rechnernetze und Internet
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220
mailto:[email-masked], http://www.net2.uni-tuebingen.de

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 12 Dec 2010 10:15:14 +0000

Hi Tom

Please see in line!

>excess-traffic-marking uses the EXP codepoint defined in RFC 5696.

Georgios: Not sure if it is good to restrict the applicability only to
RFC 5696.

>that. If they do, the discussion probably belongs in the PDB template.

Georgios: I think that PCN PCN overrides end to end ECN. I do not think
that it is needed to discuss this in the edge behaviour drafts.

>values for T-maxsuppress and T-fail.

Georgios: Okay, but use the approach proposed by Toby in a previous email.

>PCN-supportable-rate to PCN-admissible-rate over all the links of the

Georgios: You are right, the value of U must be greater than or equal to
1.

Best regards,
Georgios

---

From: "Toby Moncaster" <[email-masked]>
Date: Sun, 12 Dec 2010 21:59:23 -0000

> Georgios Karagiannis
> Sent: 12 December 2010 10:15
> To: Tom Taylor; pcn
> Subject: Re: [PCN] A couple of proposed technical changes and one
> and
> reference

Perhaps it could be RFC5696 (or any encoding that succeeds it) to allow for
the possibility of 3-in-1 becoming a STDs track document eventually.

> ECN

Indeed. That is for encoding documents!

> Georgios: You are right, the value of U must be greater than or equal

And needs a brief explanation as suggested by Michael...

Toby