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

[Patrick McManus <[e-mail]>]

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.

Thirdly, is there advice given or implied for middleboxes that see data
spud packets on opening tubes? 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.

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

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.

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.

Again, thanks for this.



>