Subject: [P2PSIP] TCP-over-UDP proposal

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 9 Apr 2009 13:25:28 -0400 (EDT)

We have written a straw man proposal for doing TCP-over-UDP (ToU).
ToU behavior is like TCP including its congestion control and reliability 
mechanisms. ToU header also mimics TCP header except port numbers, 
checksum, and urgent options.

Comments are appreciated.

http://www1.cs.columbia.edu/~salman/I-D/draft-baset-tsvwg-tcp-over-udp-00.html

Salman

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Apr 2009 13:56:22 -0400

Salman Abdul Baset wrote, On 04/09/2009 01:25 PM:
> ToU behavior is like TCP including its congestion control and
> reliability mechanisms. ToU header also mimics TCP header except port
> numbers, checksum, and urgent options.
> 

Keep the implementation details minimal. For example, Figure 2 is wrong for a
hybrid kernel- and user-space implementation I have in mind. Just focus on the
protocol. I'd remove Figure 2 and all text between the start of Section 2 until
the start of 2.1.

Section 5: Why not simply define a new protocol number and reuse all the current
function? e.g. socket( AF_INET, SOCK_STREAM, IPPROTO_TOU ); ...

Thanks,
Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 9 Apr 2009 14:35:36 -0400 (EDT)

> protocol. I'd remove Figure 2 and all text between the start of Section 2 until

Right. There may be several ways of implementing this.

> function? e.g. socket( AF_INET, SOCK_STREAM, IPPROTO_TOU ); ...

Indeed, reusing all the current functions is the preferred approach. 
However, an intermediate solution may be needed until the current function 
calls don't support it.

-s

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Apr 2009 14:42:24 -0400

Salman Abdul Baset wrote:
> However, an intermediate solution may be needed until the current
> function calls don't support it.

Right. However I see this as being out of scope for this draft. Applying
for a protocol number, though, might be in scope.

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Apr 2009 14:44:45 -0400

> for a protocol number, though, might be in scope.

Of course that protocol number wouldn't be used on the wire or otherwise
the whole "over UDP" thing wouldn't work. ;)

Hmmm... maybe there's a better way to make it fit into the BSD sockets
API...

Simon

---

From: Sam Ganesan <[email-masked]>
Date: Thu, 9 Apr 2009 19:39:52 -0400

Somebody took Jonathan Rosenberg seriously when he said this in what  
was it - was it Dublin or was it Philadelphia may be even Vancouver...

Some of the old hands might remember something called RDP which was  
sort of lightweight TCP without the burdens of full blown tcp.  As I  
remember it, it provided acknowledgement of data delivery and tried to  
minimize retransmissions.  There were even two versions of it... Let  
me look it up...

yep

rfc 908 and rfc 1151....   I remember thinking about it as UDP with  
sequencing facility and retransmission!!!

Well TCP over UDP over TCP when you have to work with tunnels???  As  
Terry Pratchett said in the Discworld series of books... "the world  
stands on 8 elephants that stand on top of a giant turtle... what does  
the turtle stand on... it is turtles all the way down"

Sorry about the tongue in cheek

So is ToU also going to have slow start in it???  and all other full  
blown TCP'isms ??? why not just define a protocol that adds retransmit  
of individual udp packets and ack mechanism and sequencing rather go  
layer a whole stack on top of another stack... Just add the features  
that are needed... Since you are proposing a new protocol anyway let  
us keep it as minimalistic as possible

Sam

On Apr 9, 2009, at 2:42 PM, Simon Perreault wrote:

> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 9 Apr 2009 20:09:03 -0400

> blown TCP'isms ??? why not just define a protocol that adds  
> retransmit of individual udp packets and ack mechanism and  
> sequencing rather go layer a whole stack on top of another stack...  
> Just add the features that are needed... Since you are proposing a  
> new protocol anyway let us keep it as minimalistic as possible

Which features would you propose to remove?

Unless you are content with stop-and-wait congestion control (and  
roughly modem data rates), you need either AIMD or rate-based control.  
As I mentioned earlier, rate-based control is not all that suitable  
for mid-sized transfers, due to the estimation delay, and isn't any  
simpler than AIMD.

Currently, ToU has

- "modern" congestion control
- flow control (window-based)
- reliability
- extensions (so that, for example, SACK can be made to work if needed)

It omits
- ports
- checksum
- urgent mode/PSH bit

I suspect we could remove RST handling, but that's a relatively minor  
aspect.

The advantage of using TCP algorithms is that it ToU behavior is  
relatively easy to validate (you can run "real" TCP and ToU in  
parallel on the same simulator, for example, and immediately see if  
you screwed up) and lots and lots of implementors understand it, as  
it's covered in every intro networking textbook. I don't think winging  
our own algorithm is a good idea, given the amount of existing "prior  
art".

As we learned from SCTP, getting the first implementations of a  
conceptually new protocol right is non-trivial. The goal would be to  
have somebody build a library, so that most application writers don't  
have to worry about getting RTO estimation right, dealing with window  
adjustments and all the other details that any non-toy transport  
protocol needs. Thus, generality is an advantage, as it encourages  
library building.

We're generally not good at predicting where and how protocols will be  
used, and most long-term successful protocols are those that provided  
modular functionality, not extremely narrowly-tailored protocols.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Apr 2009 09:38:22 -0400

Not sure what aspect your question refers to, but let me try two angles:

- SCTP does not run over UDP, so it does not address the design  
constraint of having a protocol that does. This design constraint  
triggered this whole discussion.

- SCTP is significantly more complicated than TCP in its  
implementation and its performance is generally the same, except in  
circumstances involving head-of-line blocking. (If you're interested,  
I can point you to some papers I've been involved with that explore  
this aspect in much greater quantitative detail.)

That said, it has long been noted that SCTP will have trouble getting  
traction in the consumer and enterprise Internet space unless it  
(also) runs over UDP, as there seem to be few NATs that know how to  
handle SCTP and thus it is effectively unusable by a fair fraction of  
the Internet user population.

Also, "converting" SCTP to use UDP is likely to be relatively easy,  
and similar to the mechanism proposed in the TCP-over-UDP draft.  
Tunneling is another approach, with a different set of trade-offs.

Also, the goal is to design RELOAD so that it could indeed use SCTP as  
one of its transports in the future if there's demand for it.

Henning

On Apr 13, 2009, at 9:30 AM, Sumit Garg wrote:

> Advantages as compared to SCTP??
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Apr 2009 09:15:46 -0700

>At 6:38 AM -0700 4/13/09, Henning Schulzrinne wrote:

For the tunnel version, are you thinking of this work:

http://www.ietf.org/proceedings/00jul/I-D/sigtran-sctptunnel-00.txt

or something else?

>one of its transports in the future if there's demand for it.

I thought that RFC 4168 laid out some decent reasons why you might
prefer SCTP to some of the other choices, but the big question seems to be:

Does anyone involved have enough pull with NAT vendors to get it
recognized so it can be deployed?

Without that, we seem to be stuck.  What amazes me is that
we're busily considering NATs for v6, despite this sort of thing.

				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Apr 2009 12:48:39 -0400

> http://www.ietf.org/proceedings/00jul/I-D/sigtran-sctptunnel-00.txt

Indeed, that's one easy option. Not sure what the liveness status of  
this draft is. Given the simplicity, I wonder why it hasn't gone  
anywhere since March 2000. (For what it's worth, the same document  
could be written for TCP as well. I'm completely agnostic as to  
whether the ToU proposal or tunneling is a better choice. There are  
some minor trade-offs in terms of port allocation and header overhead,  
but they are pretty trivial.)

> we're busily considering NATs for v6, despite this sort of thing.

Right, but that's probably a bit beyond the pay grade of this working  
group to fix...

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Apr 2009 17:31:51 -0500

> recognized so it can be deployed?

By definition, no. The vast majority of residential/soho NATS  
currently in-use are effectively not upgradeable; the support contract  
for their firmware between the "brand" vendor and the actual  
manufacturer lapsed years ago, and as a consequence, their software  
isn't being updated. Ever again.  I personally own a dozen or so  
devices in this category, from brands like Linksys, Netgear, Apple, D- 
Link, and others.

The only reason anybody can consider IPv6 NAT support as an option is  
that we figure everybody that wants v6 is going to have to buy a new  
NATrouter anyhow. Of course, 1) that's a major barrier to v6  
deployment in general, and 2) there's effectively only a six-month  
window to get new features into that generation of products before it  
too is frozen by aging in the installed base.

--
Dean

---

From: <[email-masked]>
Date: Tue, 14 Apr 2009 13:49:14 +0200

Henning wrote

> protocol needs. Thus, generality is an advantage, as it encourages  

Having done a user space implementation of TCP some years ago, I'd say
that it is easy to get it running, but hard to get a really good TCP
with decent throughput. Re-transmission tends to hide your bugs. Modern
TCP implementations use a number of optimizations that are not
documented in RfCs. 

As a user-space TCP needs timers, the networking code will be more
complicated than ordinary socket code. 

Many OSes started with a BSD TCP stack and ran into unexpected
difficulties when they tried to replace it with a home-grown solution. 

TCP-over-UDP is not exactly a lightweight solution..

Wolfgang

---

From: <[email-masked]>
Date: Wed, 15 Apr 2009 10:07:59 +0200

The figure in seection 2 describes ToU as a library. This is desirable
for quick adoption, but is basically an implementation detail.

The socket-like API in section 5 is of limited use if you want to mix
ordinary file descriptors and libraries with ToU sockets (eg
gtk_input_add, or Qt's QSocketNotifier). DLL trickeries might give
better results.

The draft doesn't discuss any timing constraints that a library
implementer would have to meet: is it enough to check timers on every
tou_ call? Or do I need a background thread?

What information needs to be shared among several applications using
ToU, like ISN and TCBs? Is this even possible if applications on a
single system use different ToU libraries?

(should this draft be discussed in p2psip or tsvwg?)

Wolfgang

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 15 Apr 2009 10:44:11 -0400 (EDT)

> for quick adoption, but is basically an implementation detail.

Indeed.

> gtk_input_add, or Qt's QSocketNotifier). DLL trickeries might give

Right. The socket-like API was merely intended as a reference.

> tou_ call? Or do I need a background thread?

This is an implementation choice: both timers on a tou_call or a 
background thread will work.

> single system use different ToU libraries?

As long as the underlying OS does not support ToU, applications on a 
single system may use multiple ToU libraries.

> (should this draft be discussed in p2psip or tsvwg?)

Yes. We presented this straw man version on p2psip mailing list since 
this WG is currently the biggest customer of ToU. We are planning to 
update the draft with the comments gathered so far, and present it to 
tsvwg.

-s

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Apr 2009 11:05:10 -0600

> (should this draft be discussed in p2psip or tsvwg?)

tsvwg