RE: [PCN] ProblemStatement Issue NEW: Notion of TRUST

Thanks Bob.
We will take this guidance.
We may just want to identify the problem PCN work may depend on,
by drilling down a bit in the problem space (The main purpose of 
bringing this issue up).

But will leave the solution space be open in PCN for now.
Hopefully some additional work are done in other IETF WGs that
PCN WG can use.

But we will not discourage (actually should encourage) people to tell us
how some of the TRUST notion issues can be solved.
Thanks!
-- Kwok --

At 11:47 AM 10/13/2006, Bob Briscoe wrote:
>Kwok,
>
>At 11:05 AM 10/11/2006, Kwok-Ho Chan wrote:
>>Ruediger:
>>I would like to include the result of these discussions into
>>future versions of the Problem Statement draft if appropriate.
>
>Feel free to use the description of the trust problem I've already 
>written in section 3 of 
><<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-cheat-01.txt>draft-briscoe-tsvwg-re-ecn-border-cheat-01.txt>. 
>Although that draft describes a solution, chartering that we will 
>solve this problem is a different matter...
>
>Trusting whether an upstream response will follow from downstream 
>congestion, is a hard problem that is currently not possible in the 
>Internet architecture. No other IETF activity has given itself a bar 
>this high (TCP and every other IETF transport assumes trust in the 
>upstream sender's response to congestion).
>
>Nonetheless, re-ECN claims to solve this problem. It claims to 
>ensure that the sender can be trusted to respond correctly to 
>downstream congestion, and everyone in the feedback loop can be 
>trusted to pass on congestion feedback honestly (without using 
>crypto). And the above border-cheating I-D addresses this problem 
>specifically for the edge-edge deployment model of PCN.
>
>However, re-ECN currently proposes to use the last undefined bit in 
>the IPv4 header so it's unlikely to happen in the same timeframe as 
>we are hoping to get PCN work to standards track.
>
>So, the current approach proposed for chartering the PCN w-g is to 
>assume trust with respect to responding to congestion, just like all 
>other IETF work does.
>
>But, the trust issue is particularly acute for inelastic flows 
>(which is why we need admission control). A few non-complying flows 
>can make /all/ other competing flows useless.
>
>In practice, PCN is actually further ahead on this issue than any 
>other IETF activity. But in the PCN charter we shouldn't commit 
>ourselves to /having/ to be further ahead than the Internet 
>architecture allows. However, we should include this very important 
>issue in the problem statement. And we should say it is the 
>standards activity most likely to be added if/when the group 
>re-charters after it has achieved it's initial objectives.
>
>In particular, we should discuss how to allow space for a solution 
>like re-ECN, when standardising a protocol encoding for PCN (re-PCN 
>if you like). I outlined a possible encoding in the above 
>border-cheating draft.
>
>If we did want to standardise re-PCN into bit 48 of the IP header, 
>the process isn't even clear. I think we could define it for 
>experimental use within a controlled region. That seems to fits the 
>sprit of the recently approved BCP on experiments in the IP header 
><draft-fenner-iana-exp-2780-05.txt>. But I can't get a clear answer 
>from anyone whether it does. Before the BCP was issued, I pointed 
>out to Bill Fenner that the BCP doesn't give the assignment process 
>for bit 48, and he decided it was best to continue not to mention it.
>
>
>Bob
>
>
>____________________________________________________________________________
>Notice: This contribution is the personal view of the author and 
>does not necessarily reflect the technical nor commercial direction of BT plc.
>____________________________________________________________________________
>Bob Briscoe,                           Networks Research Centre, BT Research
>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196