Re: [Spud] [Stackevo] New Version Notification for draft-trammell-stackevo-newtea-00.txt

[Ted Hardie <[e-mail]>]

On Thu, Mar 12, 2015 at 3:15 PM, Brian Trammell <[e-mail]> wrote:

>
>
> >  Doing it at above that layer with a long-lived cryptographic token has
> very serious privacy implications and doing it without one means you can
> mint an identifier freely. A reputation that lasts for the duration of the
> flow doesn't have these issues, and it may be the best we can do at the
> moment.
>
> This is another way to do it, though of course you can also always freely
> mint another flow (with SPUD, merely by opening another tube on the same
> fivetuple, even).


Y​ou're right, though the points Joe made about dispatching might come into
play here.  Anything like a load balancer that is using the identifier to
manage a state table will treat a new identifier as a new flow; that may
mean dispatching it to a new backend.  So an endpoint can do that, but it
is not guaranteed to avoid other side effects.



> Endpoints, though, are in a much better position to evaluate the
> trustworthiness of path declarations, and in this case a coarse
> remote-endpoint address identifier with a time decay function is probably
> sufficient. Whether that actually improves quality of connectivity/service
> for those endpoints is another question.
>
>
I
​ ​think we need to be careful not to over-promise here.  An initial state
might be some rate X for verification, with reputation allowing you to
reduce X (or bad data causing you to maintain or increase it).  There are
other options, of course; in a multi-link system, indications that the path
via one link has path elements which are giving you bad/false data might
cause you to consider paths using the other link, but this is definitely
trending into the "try it after proving simpler stuff works" area.

regards​,

Ted



> > Thanks again for kicking off the discussion,
>
> And thanks for continuing it.
>
> Cheers,
>
> Brian
>
> > Ted
> >
> > On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell <[e-mail]>
> wrote:
> > Greetings, all,
> >
> > Shortly before the Monday deadline, I threw together a couple of
> thoughts into a document that might eventually evolve into a more
> architectural view of the vocabulary of the things we can expect to be able
> to deployably say with SPUD (separate from the current discussion on the
> scope of the tube ID). This follows from discussions about trying to keep
> markings declarative.
> >
> > Comments welcome.
> >
> > Thanks, cheers,
> >
> > Brian
> >
> > > Begin forwarded message:
> > >
> > > From: [e-mail]
> > > To: "Brian Trammell" <[e-mail]>, "Brian Trammell" <
> [e-mail]>
> > > Subject: New Version Notification for
> draft-trammell-stackevo-newtea-00.txt
> > > Date: 9 Mar 2015 18:41:02 CET
> > >
> > >
> > > A new version of I-D, draft-trammell-stackevo-newtea-00.txt
> > > has been successfully submitted by Brian Trammell and posted to the
> > > IETF repository.
> > >
> > > Name:         draft-trammell-stackevo-newtea
> > > Revision:     00
> > > Title:                Thoughts on New Transport Encapsulation
> Approaches
> > > Document date:        2015-03-09
> > > Group:                Individual Submission
> > > Pages:                6
> > > URL:
> http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.txt
> > > Status:
> https://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/
> > > Htmlized:
> http://tools.ietf.org/html/draft-trammell-stackevo-newtea-00
> > >
> > >
> > > Abstract:
> > >   This document presently consists of a collection of unordered
> > >   thoughts about new approaches to using encapsulation in support of
> > >   stack evolution and new transport protocol deployment in an
> > >   increasingly encrypted Internet.  It aims eventually to enumerate a
> > >   set of architectural assumptions for transport evolution based upon
> > >   new encapsulations, and discuss limitations on the vocabulary used in
> > >   each of these new interfaces necessary to achieve deployment
> > >
> > >
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> submission
> > > until the htmlized version and diff are available at tools.ietf.org.
> > >
> > > The IETF Secretariat
> > >
> >
> >
> > _______________________________________________
> > Stackevo mailing list
> > [e-mail]
> > https://www.iab.org/mailman/listinfo/stackevo
> >
> >
>
>