InitiateAndSend() / RendezvousAndSend() #214
Conversation
I don't mind InitiaiteAndSend(), although I'd bike-shed the name, but RendezvousAndSend() needs more thought...
draft-ietf-taps-interface.md
Outdated
|
|
||
| ~~~ | ||
| Connection := Preconnection.InitiateAndSend(messageData, messageContext) | ||
| ~~~ |
There was a problem hiding this comment.
I like the general approach of InitiateAndSend. It keeps the types right, and avoids issues with trying to call Send() on Preconnection objects and with enqueued data.
Maybe suggest changing the name to InitiateAndSendIdempotent() though, to be explicit? There are security issues with idempotent data, so we need to (try to) make sure people don't use without thinking through the consequences.
There was a problem hiding this comment.
I agree, being explicit here would be important.
There was a problem hiding this comment.
+1 to change to InitiateAndSendIdempotent(), since it forces that message property.
There was a problem hiding this comment.
<bikeshed> How about InitiateWithIdempotentSend()? </bikeshed>
draft-ietf-taps-interface.md
Outdated
| establishment. | ||
|
|
||
| ## Send on Rendezvous: RendezvousAndSend {#rendezvous-and-send} | ||
|
|
There was a problem hiding this comment.
I guess we need to think more about the rendezvous model.
If the goal is to support traditional TCP simultaneous open, then 0-RTT idempotent data could work. For something like an ICE-driven rendezvous, with NAT traversal, I wonder if it still makes sense? STUN doesn't support delivering data in the binding discovery messages, so it's no longer 0-RTT. And, if some future protocol did support data in binding discovery messages, there's no guarantee that all those messages hit the same server, so the semantics get weird.
I wonder if we should not try to support idempotent, 0-RTT, rendezvous for the first version?
There was a problem hiding this comment.
Sounds reasonable to leave it out for now.
There was a problem hiding this comment.
Yeah, I tried this out primarily to see what would happen if RendezvousAndSend() were kept consistent with InitiateAndSend() and you get this weird buffered-banner behavior that (1) probably doesn't do anything anyone wants and (2) also probably doesn't work anyway.
Will cut it for now, and we can leave rendezvous acceleration as an area for future research.
|
After some discussion with Brian I agree that the only solution is to provide some initial date to the preconnection when calling initiate. However, why do we need to have two different function. If we only have initiate and provide idempotent data as an optional input parameter that should be fine, right? |
This is my attempt to address #112 with something that's (IMO) less clunky in the common case than #124.
I'm not a big fan of this way of doing things either -- specifically, I think the semantics of RendezvousAndSend(), while consistent, are probably wrong.