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

[Bob Briscoe <[e-mail]>]

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" rel="nofollow">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.    [phone]

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