Re: [OFF-PATH-BOF] SIP, naming, APIs and control

On Fri, 2006-07-28 at 14:52 +0200, Scott W Brim wrote:
> On 07/14/2006 18:20 PM, Saikat Guha allegedly wrote:
> > OFF-PATH signaling, synonymous with DATA-DECOUPLED signaling, refers
> > to the case where signaling packets (at least the first signaling
> > packet) _necessarily_ take a path different than the DATA-PATH.
> 
> First I want to push for a few terminology nits ...
> 
> Technically they are not synonymous, at least in some circles.  

Agreed. I should have used different terms; what I was trying to get at
was a slightly broader picture of a communication session between two
endpoints.

Take an FTP transfer for instance between client C and server S.
Consider how it would be accomplished in various architectures today.

Arch #1: Internet before DNS
----------------------------
1. Assumption: C must know S's IP address.
   - How? Business card, phone call, ... somehow
2. C sends a TCP SYN to S's IP address
   - This 'signal' follows the same path that data will eventually
     follow. 
3. Over the signaling channel in #2, C sends a request. S opens a 
   data connection by sending another SYN signal. Data can now flow.

#1 = assumption: knows IP address
#2 = end-to-end signal
#3 = end-to-end data

Arch #2: Internet with DNS
--------------------------
1. Assumption: C must know S's hostname
2. C does a DNS request to it's local resolver
   - This 'signal' is along a different path than the e2e path that
     the data will eventually take
3. Same as #2 above
4. Same as #3 above.

#1 = assumption: knows hostname
#2 = end-to-middle signal
#3 = end-to-end signal
#4 = end-to-end data

Arch #3: With SIP/ICE/NAT-Traversal
-----------------------------------
1. Assumption: C must know S's URI
2. C sends 'INVITE' to S over SIP
   - This path _may_ be different from the ultimate e2e data path
3. S responds with a transient IP address/port pair over SIP
4. Same as #3 above
5. Same as #4 above

#1 = assumption: knows URI 
#2 = end-to-middle-to-end signal (possible disjoint from data-path)
#3 = end-to-middle-to-end signal (possible disjoint from data-path)
#4 = end-to-end signal
#5 = end-to-end data

Arch #4: With TURN relay in addition with SIP/ICE/...
-----------------------------------------------------
1. Assumption: C must know S's URI
2. Same as #2 above
3. Same as #3 above, except returns a TURN server's address
4. C sends a SYN to the TURN server, TURN server connects to S
5. For data conection, S connects to TURN server, which connects to C

#1 = assumption: knows URI
#2 = end-to-middle-to-end signal (possible disjoint from data-path)
#3 = end-to-middle-to-end signal (possible disjoint from data-path)
#4 = end-to-middle-to-end signal (along data-path)
#5 = end-to-middle-to-end data

So basically, I was shooting for terms to differentiate the various
components of these architectures.

a) end-to-middle signal                  (DNS, UPnP, ....)
b) end-to-middle-to-end signal           (SIP, i3, TURN, NSIS, ...)
   b1) not necessarily along data path     (SIP, i3, ...)
   b2) along the data path                 (TURN, NSIS, ...)
       b21) same "flow"                      (TURN, ...)
       b22) different "flow"                 (NSIS, ...)
c) end-to-end signal                     (TCP SYN, ...)
d) end-to-end data                       (TCP Data, ...) 
e) end-to-middle-to-end data             (TURN Data)

-- 
Saikat

Re: [OFF-PATH-BOF] SIP, naming, APIs and control

Attachment: signature.asc