Subject: [tsv-area] TANA comments

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 28 Jul 2008 04:04:54 -0500

The TANA BoF hasn't happened yet, and I'll be on a plane when it does, but I've looked at the problem statement and have a few short comments:
 
(1) I have no idea what an "advanced networking application" is.  I suggest actually defining this or finding a more precise term.  I assume you don't mean advanced in terms of age :).
 
(2) On "multiple connections" between 2 peers, this only has meaning when talking about TCP applications, with UDP it doesn't matter how many port pairs you use, the sending behavior can be the same.  The only difference is that with multiple UDP sockets you have multiple socket buffers to fill and the kernel may drain them in some different pattern than if you wrote all the packets to the same UDP socket.
 
(3) There is ambiguity about what transport services the targetted applications need; if it's datagram or reliable bitstream, either, both, etc.  It may not actually matter, but it might be useful to know in determining what work is actually needed here.
 
(4) The problem statement mentions that there is already a fielded solution.  Is the purpose of this activity to write up that solution, or to work on creating solutions?

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 28 Jul 2008 03:52:46 -0700

On Jul 28, 2008, at 2:04 AM, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> (1) I have no idea what an "advanced networking application" is.  I  
> suggest actually defining this or finding a more precise term.  I  
> assume you don't mean advanced in terms of age :).

I'm not sure how the name of the BoF came about.  The motivation is  
P2P apps, but this should be applicable well beyond.

> (2) On "multiple connections" between 2 peers, this only has meaning  
> when talking about TCP applications, with UDP it doesn't matter how  
> many port pairs you use, the sending behavior can be the same.  The  
> only difference is that with multiple UDP sockets you have multiple  
> socket buffers to fill and the kernel may drain them in some  
> different pattern than if you wrote all the packets to the same UDP  
> socket.

It looks like the whole thing of multiple connections to single peer  
is a red herring.  We couldn't come up with an example of a P2P app  
that were designed to open multiple connections to the same peer.   
(BitTorrent has client ids partly to prevent this from happening by  
accident, for example.)  It'd be pretty pointless anyway.

> (3) There is ambiguity about what transport services the targetted  
> applications need; if it's datagram or reliable bitstream, either,  
> both, etc.  It may not actually matter, but it might be useful to  
> know in determining what work is actually needed here.

Excellent question.  Thus far, byte stream has been the only useful  
service from my perspective, even for video streaming.  But datagram  
service might be useful to other people or some time in the future,  
and perhaps even reliable datagram.  What do you think?

> (4) The problem statement mentions that there is already a fielded  
> solution.  Is the purpose of this activity to write up that  
> solution, or to work on creating solutions?

The purpose of the activity is to create a standard solution.  The  
fielded work is only mentioned as proof-of-concept of possibility.

--
Stanislav Shalunov