[Spud] draft-mihaly-spud-mb-communication (Was: SPUD Scope?)

[Szilveszter Nadas <[e-mail]>]

Hi,

We wrote a draft about our ideas on how to support uneven resource sharing among users in the SPUD way. We intend to show a way forward in addressing the following concerns:
-The endpoints have an incentive to lie, how can we create the right incentive for them to ask for higher resource share only when they need it.
-The choice of QoS shall be given to user, to be fair. At the same time this would require bothersome user interaction, which would itself ruin the experience of the user.

We tried to design a framework that builds on the existing QoS architectures and the existing subscription models, and where the users may control which applications and when to use a specific service delivery option. Last but not least, it is fair to the users. We exploit the Advantage of SPUD (-like) protocol: simple in-band signaling where with incremental usefulness where no mandatory minimum vocabulary needed, ensures data confidentiality.

Comments are welcome!

Cheers,
Sz.

Name:		draft-mihaly-spud-mb-communication
Revision:	00
Title:		Middlebox Communication Enabling for Enhanced User Experience
Document date:	2015-07-06
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-mihaly-spud-mb-communication-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mihaly-spud-mb-communication/
Htmlized:       https://tools.ietf.org/html/draft-mihaly-spud-mb-communication-00


Abstract:
   In this draft we address some of the key discussion points related
   to the scope of Substrate Protocol for User Datagrams (SPUD).
   Specifically, we show how we can define the middlebox communication
   framework such that it allows uneven resource sharing on the path
   among the endpoints enhancing in this way the user experience.
   Issues related to trust and incentives as well as how to support
   user decisions in this eco-system are clarified.




-----Original Message-----
From: Spud [mailto:[e-mail]] On Behalf Of Szilveszter Nadas
Sent: Monday, June 08, 2015 16:20
To: FOSSATI, Thomas (Thomas); Ken Calvert; Daniel Kahn Gillmor
Cc: [e-mail]
Subject: Re: [Spud] SPUD Scope?

Hi,

>>Yes, the path is fraught with challenges; I don't disagree with most 
>>of your points.  On the other hand, call me an optimist, but I believe 
>>such a mechanism could not only help break the "ossification" logjam, 
>>but perhaps eventually shift the balance of power back toward the end 
>>users by giving them more choices w.r.t. network services.

I share the same belief.

I think that middleboxes must demonstrate their value for one of the ends in order to receive metadata. This is what I mean on them being explicit. However if they do demonstrate then I believe in giving them the information they want. 

I personally prefer that even without metadata a reasonable default service is available. How to achieve this is a good question. I guess regulators have bigger rule here than engineers. Though I believe that engineers are responsible to educate regulators to find the right path. Without the right regulation blocking when not getting metadata can always happen even if we make it harder with protocol design.

>I totally agree with you, as long as the underlying principles are:
>- explicit vs implicit service;
>- ability of endpoints to choose based on clear information about the 
>service value vs leaked meta-data;
>- preservation of e2e security properties.
>
>I think the biggest (though not insurmountable) challenges are:
>- UX (as already noted by Daniel);
>- scale mechanism to n middle boxes.
>
>We probably need a good deal of research to solve scale and UX, and I hope stackevo has enough breath to account for this.

I agree. I am thinking about writing a draft along these lines and also include some example use cases with "good" cooperation examples.

Cheers,
Sz.

_______________________________________________
Spud mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spud