Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt

["Joe Hildebrand (jhildebr)" <[e-mail]>]

On 3/6/15, 1:52 PM, "Patrick McManus" <[e-mail]> wrote:

>First - Thanks Joe and Brian. I have a few margin notes to share :)
>
>Next, I may just be confused because I have read the text less than the authors at this point, but it seems as if unidirectional flows are off the table.. the text doesn't really say this, but the open-ack seems to imply it. There certainly are unidirectional
> udp flows but some clarification would help.

It wasn't my intent to rule them out, but we probably need to think about how to ensure that the state transitions make that more clear.

>Thirdly, is there advice given or implied for middleboxes that see data spud packets on opening tubes? 

Not yet.

>The only thing I really see about the opening state is the diagram - but the diagram applies to the endpoint, not to the middlebox state, right? I'm
> concerned the text will read like there needs to be a full rtt handshake before data packets can flow on a spud tube and there are counter examples to things we would like to run on spud already.

Agree.  This really isn't clear yet and it needs to be.

>Fourthly, there are a couple "reserved bits MUST be zero".. should that be "senders MUST set to zero, receivers MUST ignore "?

Yes.  Willfix.

>Fifthly, on the topic of whether tube-ids need a consistent 5 tuple, I think there are several cases where it would be nice if they didn't..  load balancers are a good example - a request is sent to a central service that parses it and dispatches it to
> the best back end server.. historically that server needs to lie about its address somehow when sending the reply (either via proxy or more likely via spoofing - and if spoofed you need to figure out the ack traffic). It would be cool to have that all in one
> tube with real addresses so the transport could decide how to deal with those issues.

I like the use case.

>Sixthly, am I misreading the 8.2 MUST that SPUD enabled NATs need to share internal addressing info on the external side of the NAT? Is that really a MUST - some folks will be frothing at the mouth with the perceived information disclosure issues.

The intent was that the mapping is only shared internally.  I'll see if I can fix the wording.

-- 
Joe Hildebrand