Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00))

[Toerless Eckert <[e-mail]>]

Counter example is when the presence of the advanced processing
that the app wants to have in the network would actually impact how the
application sends packets. For example if i can know at least one middlebox
can do advanced priority based packet dropping, then i'd do the video encoding
slightly different.

And i still contend that privacy advocats would think it is less intrusive
if you have the ability to signal your tokens only after figuring out why
what you get for it). Independent of whether the app would change it's behavior.

Cheers
    Toerless


On Mon, Aug 10, 2015 at 01:02:39PM -0700, Ted Hardie wrote:
> On Mon, Aug 10, 2015 at 12:40 PM, Toerless Eckert <[e-mail]> wrote:
> 
> > ;-) Thanks for detailling the minimum requirements for the example
> > exchange. But my point was really about showing the <insert right token>
> > only after you know why you would have to show it.
> >
> 
> If i read your reply correctly, you are reconfirming
> > that the current goal in SPUD is to show tokens whether or not they are
> > needed
> > and without knowing what benefit you would get when you show them. Its like
> > carrying that vertical or hirozontal picture card openly without knowing
> > that you'll have a benefit from it.
> >
> > ???So, let's assume that the request is from an application like a WebRTC
> application working inside a browser.   It wants to tell the network that a
> specific set of packets are grouped together (they are a tube) even when
> there are other packets on the same five-tuple.  For the ones within the
> tube, it would prefer packet drop on delay, rather than buffering.  Sure,
> it could wait until every middlebox along the way reported its likely
> treatment of the tube before specifying what it wanted, but it is faster
> and more reasonable to make the declarative statement when the desire is
> expressed.
> 
> That's more like, "show the picture when you are entering bar, rather than
> waiting to see if a bouncer asks for your ID"???.  Yes, the bouncer might
> look at you and pass you based on inference, but why rely on that?
> 
> Ted
> 
> 
> 
> 
> > Thats what i think is one of the main reasons why we have this ongoing
> > discussion
> > between privacy and spud sides. If spud had the framework to tell
> > the how what to show and what benefit it would then get, i am arguing
> > the pushback would be a lot smaller.
> >
> > Cheers
> >     Toerless
> >
> > On Mon, Aug 10, 2015 at 12:12:12PM -0700, Ted Hardie wrote:
> > > Howdy,
> > >
> > > On Mon, Aug 10, 2015 at 11:41 AM, Toerless Eckert <[e-mail]>
> > wrote:
> > >
> > > > As a generic side thought based on Christians concern about privacy
> > > > (why would an app want to show a shared Tube-ID across multipath/mobile
> > > > flows for example).
> > > >
> > > > To me, the problem is best explained on the following workflow:
> > > >
> > > > "Here is your new ID card".
> > > > "Why would i want to have an ID card, everybody who checks ID cards is
> > > > evil"
> > > > "You do not have to show your ID card if you don't want to"
> > > > "Lets go to the bar"
> > > > "ID card please"
> > > > "Booze or anonymity... that's the question"
> > > > "Lets choose booze"
> > > >
> > > >
> > > ???You've just demonstrated a bad workflow.  To drink booze in many
> > > jurisdictions, you need to be of a certain age.  Associating that age
> > with
> > > a token that can be shown (of-booze-consuming-age) is enough to meet the
> > > requirement; showing an identity is most assuredly not required.
> > >
> > > There are states that change your ID card when you pass that age, for
> > > example; it is a horizontal picture in one and ???a vertical in the
> > other.
> > > When asked for proof of age, you can show just the picture and be granted
> > > entrance, without showing your name, home address, or other identifying
> > > characteristics.
> > >
> > > What we are looking for in SPUD is a set of declarative statements that
> > can
> > > be made from the application to the network about the network treatment
> > > desired and from the network to the application about the network
> > treatment
> > > provided.  Anything beyond that is not just surplus to requirements, it's
> > > dangerous because you can end up subverting the security properties of
> > the
> > > overlying protocol (which is what the application sees and is relying
> > on).
> > >
> > > My two cents, in any case,
> > >
> > > Ted
> > >
> > >
> > >
> > >
> > >
> > > > So, whats missing in SPUD (or any prior endpoint<->network) signaling
> > is
> > > > the
> > > > signaling element "If you do not show ID card, you will not get booze"
> > or
> > > > "if you do not use a cross-subflow Tube-ID, your load-sharing,
> > mobility or
> > > > multipath
> > > > performance will suck or not work".
> > > >
> > > > Using the same Tube-ID is just one example. This interaction really
> > applies
> > > > to any possible signaling element: The anonymity freak will argue to
> > his
> > > > death that he doesn't want to provide information to the network...
> > unless
> > > > the network can persuade him that the benefit of showing outweights the
> > > > loss of anonymity.
> > > >
> > > > This is primarily a question of creating a data-model of what the
> > network
> > > > can offer
> > > > and tie that to a data model for what to show to get it....
> > > >
> > > > Cheers
> > > >     Toerless
> > > >