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

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Oct 2006 16:47:42 +0100

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
<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

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

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 13 Oct 2006 12:49:38 -0400

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:
>>future versions of the Problem Statement draft if appropriate.
>
><<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...
>
>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 
>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