Subject: Re: [PCN] PCN Encoding Comparison Draft Open Issues

From: Bob Briscoe <[email-masked]>
Date: Tue, 04 Dec 2007 01:59:48 +0000

Kwok,

Issue #3e
Is(are) "nounce" encoding state(s) needed?

Some background, then my opinion at the end...

Validation of a nonce is typically done by taking the sum of all the nonces 
between one feedback signal and the next. In general this requires 
identifiable checkpoints to start and end the calculation over all the 
intevening nonces. Therefore, between PCN boundary nodes, a nonce only 
works if the packets can be reliably identified and ordered in the same way 
by the ingress and the egress.

As PCN ingress nodes don't add sequence numbers or use existing sequence 
numbers and the egress doesn't read sequence numbers or correct any 
misordering, a nonce would not ever be ever able to be reliably validated 
by the boundary nodes.
The only possible need for the nonce is if ECN is also being used e2e, and 
the endpoints validate the ECN nonce with their knowledge of packet ordering.

What would be the implication of re-using an ECN-nonce codepoint if the 
source did deploy the nonce? Let's imagine the PCN w-g decided to re-use 
one of the ECN nonce codepoints for (say) admission marking. If a source 
encoded a nonce into a packet stream but the PCN ingress overwrote the 
nonce codepoint to ensure it wasn't misinterpreted as (say) admission 
marking within the PCN domain, the source would think that something along 
the path or the receiver was 'cheating' in some way. In RFC3540 it's up to 
the source what to do in this case. It might stop sending if it thinks the 
receiver is cheating. But nothing would break if the source decided to just 
carry on even tho something might be cheating. However, a bad precedent 
would be set overloading a header codepoint without any negotiation mechanism.

RFC3540 (the ECN nonce) is experimental having attained that status in Jun 
03. It hasn't been implemented by anyone (yet), except one instance by the 
main author which has not been deployed or made available as binary or source.

My tuppence worth would be that, if we decide to somehow use the ECN 
codepoints for PCN codepoints, there would be no problem also re-using the 
ECN nonce for PCN codepoints. Ie, PCN can't use a nonce itself (because of 
the re-ordering issues above).

HTH

Bob

At 19:46 30/11/2007, Kwok-Ho Chan wrote:
>If you have problem with the link to the Issues List,
>You can use the link:
>http://standards.nortel.com/pcn/PCN_Encoding_Comparison_Draft_OpenIssues.txt
>
>Sorry for any inconvenience.
>-- Kwok --
>
>At 02:26 PM 11/30/2007, you wrote:
>>The current open issues for:
>>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-01.txt
>>are documented at:
>>http://standards.nortelnetworks.com/pcn/PCN_Encoding_Comparison_Draft_OpenIssues.txt
>>
>>This file will be updated based on discussions and resolutions of these 
>>and additional
>>open issues for the draft.
>>
>>Please review the draft and the issues list.
>>
>>E-Mail list discussions on the open issues should have:
>>"EC Issue 03.c" as the start of the E-Mail subject field for
>>"PCN Encoding Comparison Draft Issue 3 Sub-Issue a"
>>to help multiple drafts, multiple issues, discussion management.
>>
>>Please let me know if you want any changes/corrections/additions to this 
>>file.
>>For example: the creation of a new issue, or sub-issue of an existing issue.
>>
>>I have the content of the Issues List cut-and-pasted below in this E-Mail.
>>But will be using the file as the master copy going forward.
>>
>>Thank you very much for your time and attention to this work.
>>-- Kwok --
>>
>>
>>Content of the PCN Encoding Comparison Draft Issues List file:
>>
>>Issues List for PCN Encoding Comparison Draft
>>=============================================
>>Updated: Nov 28, 2007
>>Editor: Kwok Ho Chan
>>Draft:
>>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-01.txt
>>
>>For further discussions, please use notations of:
>>- EComp03.c is used to reference Encoding Comparison draft Issue "03.c".
>>- "chan-01" is used to reference version -01 of the personal draft.
>>
>>
>>Issue #1: ECN Support in a PCN Domain
>>=====================================
>>The resolution of this issue will clarify how a PCN Domain needs
>>to treat ECN (RFC3168) packets, in terms of Interior Nodes and
>>Edge Nodes.  This issue arise with discussion on the Architecture
>>draft, but this will definitely impact the PCN Encoding Comparison
>>draft, with possible impact on the algorithm discussions.
>>The resolution of this issue will also solidify the definition of
>>a PCN Domain.
>>The starting point will be: Does the use of DiffServ sufficiently
>>define the logical boundaries of a PCN Domain?  Logical because
>>the same physical network device (router,switch,etc) may support
>>a PCN Domain as well as some other non-PCN domains.
>>
>>
>>Issue #2: Deletion of the Out of Band Channel Section
>>=====================================================
>>It have been proposed to remove chan-01 section 3.4 Out-of-Band
>>Channel as Encoding Transport.  This is considered to be out of scope
>>for the WG.  Would like some agreements on the list before removal.
>>
>>
>>Issue #3: Encoding States
>>=========================
>>The Encoding States indicated in chan-01 section 2 Encoding Requirements
>>needs to be better defined and clarified.
>>More specifically:
>>a. Removing PCN Capable Transport Marking (Non-PCN Capable Transport
>>    Marking) as a notion of Encoding State, just indicate the need
>>    for this separation as a requirment (possibly in the Architecture).
>>b. Better explanation/indication of Single Marking for both Admission
>>    Marking and Termination Marking
>>c. Possible additional encoding choices when DSCP+ECN fields are used.
>>d. Which Encoding States should the WG require?
>>    Should there be optional Encoding States?
>>    And their deployment options.
>>e. Is(are) "nounce" encoding state(s) needed?
>>
>>
>>Issue #4: Encoding Option Evaluation Criteria
>>=============================================
>>Need to add a section that indicates and describes the encoding option
>>evaluation criteria.  May want to add OAM impacts/considerations here or in
>>some new section.
>>
>>
>>Issue #5: Co-existence of PCN and ECN without use of tunnel
>>===========================================================
>>Need to determine if this should be addressed by this draft.
>>
>>
>>Issue #6: Use of PCN by multiple DiffServ Classes
>>=================================================
>>This can be added to the Intro section of this draft.
>>But this discussion may be more appropriate in the Arch draft.
>>
>>
>>Issue #7: ECMP considerations for PCN Encoding
>>==============================================
>>This should be one of the Encoding Option Evaluation Criteria.
>>But may also want to add new subsections under each of the
>>encoding choices on how they address this (and other) encoding
>>option evaluation criterion.
>>
>>
>>Issue #8: Document organization and text cleanup/addition
>>=========================================================
>>There are number of open issues relating to possible document
>>organization changes and addition of new text (or clean up of
>>existing text).  One of them is expansion on tunneling's impact
>>on encoding options.  Fixes to typo should also be part of this.
>>
>>
>>
>>
>>_______________________________________________
>>PCN mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/pcn
>
>
>
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pcn

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

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

---

From: <[email-masked]>
Date: Tue, 4 Dec 2007 18:01:32 -0000

I reaalise we discounted the nonce anyway at the meeting yesterday but I just thought I would add a bit...
 
AFAIK we were currently running with the assumption (in architecture draft) that all nodes in the PCN domain are trusted. THis trust assumption is explicitly mentioned in the initial charter as assumption (A). That would leave the nonce purely being used as a test for errors rather than as a test for accurate reporting as it is used in RFC3540.
 
Toby
 
______________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473 648734

________________________________

From: Bob Briscoe [mailto:[email-masked]]
Sent: Tue 04/12/2007 01:59
To: Kwok-Ho Chan
Cc: [email-masked]
Subject: Re: [PCN] PCN Encoding Comparison Draft Open Issues

Kwok,

Issue #3e

HTH

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 04 Dec 2007 19:11:20 +0000

Toby,

Well, strictly, the charter says we should 'keep inter-domain in mind', so 
we certainly shouldn't assume trust when it comes to precluding future use 
of codepoints.

But the previous point still holds - if we find a way to get the other ECN 
codepoints across a PCN domain, /another/ PCN nonce for use purely between 
the PCN edge nodes wouldn't work anyway.

Bob

At 18:01 04/12/2007, [email-masked] wrote:
>AFAIK we were currently running with the assumption (in architecture 
>draft) that all nodes in the PCN domain are trusted. THis trust assumption 
>is explicitly mentioned in the initial charter as assumption (A). That 
>would leave the nonce purely being used as a test for errors rather than 
>as a test for accurate reporting as it is used in RFC3540.
>
>Toby
>