Re: [Stackevo] Fwd: New Version Notification for draft-trammell-spud-req-01.txt

[Mirja Kühlewind <[e-mail]>]

Hi all, hi Brian,

(Only replying to stackevo as this is mostly on the explicit-coop doc.)

I finally had a chance to read the new explicit-coop doc and for me the split 
between spud requirements and explicit coop is still not clear (said this to 
Brian in person already a while ago).

The only split that would make sense to me would be on the technical 
requirement regarding the protocol design vs. requirements/constrains on the 
information exposed in such a protocol. Regarding architectural 
consideration, from my point of view, there is actually not much to say here: 
you have an endpoint and a middlebox and you want to exchange information 
about the traffic that is send though the middlebox and generated by the 
endpoint. For me e.g. in-band vs. out-of-band is a protocol question. The 
only question that is maybe related to the architecture, but again depends 
strongly on the kind of information exchanged, is the level of trust that is 
needed between the ends and the middle(s).

So for me section 3.6. and 3.7. of the explicit coop doc actually belong in 
the requirement doc and I believe that it even would be helpful to state the 
constrains on information that might be exposed using such a protocol in the 
same doc than any requirement on the protocol.

Further reading Brian's mail below, it might that the question of the scope 
of the tube ID is rather a question related to the information exposed (than 
something that would actually influence/change the protocol design itself). 
However, I think this discussion should really be in the spud requirements 
doc (maybe rather moved to the discussion section than being an actual 
requirement... not sure).

I guess the only thing the IAB could actually provide advise/guidance here, 
is how to resolve the tussle between privacy and functionality. However, I 
don't have a general solution here. One principle is here that one should 
always only expose the minimum amount of information needed; but what is the 
minimum in each single case...? Further I think that it is a good idea to 
give choices to the user, as currently proposed in section 3.5; however, this 
leads to another hard problem about representing the information such that 
the user is able to act accordingly.

Further, see one tiny comment below.

Mirja


On 20.10.2015 21:58, Brian Trammell wrote:
> Greetings, all,
>
> We've submitted a new revision -01 of the SPUD requirements document, following discussion in Prague and on the list in August (yes, it's taken us quite a while to get back to this). We seem to be... slowly... converging on a set of requirements here.
>
> In addition, we're collecting general architectural issues that would effect *any* attempt to build explicit cooperation between endpoints and on-path devices into a potential future IAB document, draft-trammell-stackevo-explicit-coop. Our intention is that these two documents evolve together, with explicit-coop being input to architectural guidance and this requirements document input to future protocol engineering efforts. One section (on in- versus out-of-band signaling) which was pretty general has been largely moved into explicit-coop. Otherwise, have a look at the diff to see what has changed.
>
> There is one big open issue from the discussion in August, not really addressed differently in -01 than in -00, which I'd like to try to summarize (my view of) and see if we can converge on, related to the scope of tube identifiers in multipath, multicast, and anycast environments.
>
> For unicast on a single path without mobility, it seems pretty clear (to me, at least) that tube identifiers should be scoped to a unidirectional 5-tuple; i.e., that the reverse side of a flow has a different tube ID, and that tube IDs need not be global. Unidirectional scope is made necessary by asymmetric routing -- the set of devices relevant to a tube in one direction is not the same as the set in the other. Local scope is made necessary by privacy requirements -- the tube ID should not expose information about the identity of the user unless the path actually needs it, and global tube IDs would do that.
>
> There should be a facility for truly unidirectional traffic to expose that one side of a bidirectional tube is related to the other side, but this would be an explicit app to path declaration on tube setup.
>
> For multipath/mobility, obviously there is a need for there to be a connection/session identifier to link 5-tuples to each other. But this is clearly a different thing than the tube ID, for a couple of reasons: (1) different paths of a multipath session might want to expose different declarations to their paths; and (2) path declarations are scoped to a tube as well, and the different paths of a multipath session will themselves have different properties.
>
> What I think we need here is a separate session ID concept, which spans multiple flows and indeed might span multiple tubes, and could be exposed to the path using SPUD depending on whether or not it's in the endpoint's interest to make the service quality vs. linkability tradeoff. (Of course, multipath transports supporting mobility this way could also use such a session ID inside the crypto veil, if there's no win to sharing with the path. But they can't decide to do this if SPUD mandates they use the tube ID in this way.)
I'm not sure if you need yet-another ID here of if it would be sufficient to 
use the tube ID for both purposes, as there is no technical reason why the 
tube ID should not group different flows together.

>
> Multicast is a related problem. The simple solution seems to be to pretend there *is* no problem, keep tube IDs scoped to the uni-5-tuple, and simply say that path to application declarations are of limited utility when the destination address is multicast. App to path still works in this case. Making tube IDs unidirectional simplifies this. Indeed, the main reason I don't advocate the "pretend there is no problem" solution with multicast is that we tend to get into trouble when we do so.
>
> The thread briefly touched on what SPUD can do for anycast -- letting the path know that one particular tube setup "won" for instance. I think this could definitely be a SPUD application, implemented with application declarations and paths that take info from the tube ACK to route that tube back along the path it came from, but enough needs to happen to all the middleboxes and routers along the path in order to make sessions "anycast-stable", that it's probably not a "core" feature.
>
> Thoughts?
>
> Thanks, cheers,
>
> Brian
>
>> Begin forwarded message:
>>
>> From: [e-mail]
>> Subject: New Version Notification for draft-trammell-spud-req-01.txt
>> Date: 19 Oct 2015 22:29:40 CEST
>> To: "Mirja Kuehlewind" <[e-mail]>, "Brian Trammell" <[e-mail]>
>>
>>
>> A new version of I-D, draft-trammell-spud-req-01.txt
>> has been successfully submitted by Brian Trammell and posted to the
>> IETF repository.
>>
>> Name:		draft-trammell-spud-req
>> Revision:	01
>> Title:		Requirements for the design of a Substrate Protocol for User Datagrams (SPUD)
>> Document date:	2015-10-19
>> Group:		Individual Submission
>> Pages:		16
>> URL:            https://www.ietf.org/internet-drafts/draft-trammell-spud-req-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-trammell-spud-req/
>> Htmlized:       https://tools.ietf.org/html/draft-trammell-spud-req-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-trammell-spud-req-01
>>
>> Abstract:
>>    The Substrate Protocol for User Datagrams (SPUD) BoF session at the
>>    IETF 92 meeting in Dallas in March 2015 identified the potential need
>>    for a UDP-based encapsulation protocol to allow explicit cooperation
>>    with middleboxes while using new, encrypted transport protocols.
>>    This document proposes an initial set of requirements for such a
>>    protocol, and discusses tradeoffs to be made in further refining
>>    these requirements.
>>
>>
>>
>>
>> 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
>