Subject: [Ietf-behave] slashdot: p2p firewalled file transfers

From: Dan Wing <[email-masked]>
Date: Tue, 23 Nov 2004 16:10:17 -0800 (PST)

My quick read is that folks are doing UDP-based file transfers because 
peer-to-peer TCP doesn't work.  And we can expect UDP-based 
implementations won't be TCP-friendly...  This seems ripe for net 
meltdown considering the claimed percentage of TCP traffic that, today, 
is p2p file sharing.

http://slashdot.org/articles/04/11/23/1755226.shtml?tid=95&tid=185

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Nov 2004 23:41:58 -0800 (PST)

Exactly the reason to try and get p2p tcp to work through a behave 
nat... it won't prevent these things from happening now, but hopefully 
it can be avoided in the future.

I hope these p2p guys consider congestion control. The reference in the 
slashdot article to udp file transfer explicitly calls out the need to 
make the udp transfer tcp-friendly, which was at least somewhat reassuring.

-Jonathan R.

Dan Wing wrote:

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: nagendra modadugu <[email-masked]>
Date: Wed, 24 Nov 2004 02:02:02 -0800 (PST)

>From the mailing list discussion of the subject, it seems
that the bandwidth allocated to a stream is fixed for now,
but will be adjusted based on RTT measurements (how to
get this all to work is a still a question).

I wonder why no-one has suggested user-land TCP to be run over
UDP--it should be easier to integrate than some new reliable
transport. 

nagendra

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 08:06:52 -0800 (PST)

TCP-over-UDP would use more bandwidth than TCP or a new 
"as-good-as-TCP" UDP-based protocol that someone will invent.

-d

On Nov 24, 2004, at 2:01 AM, nagendra modadugu wrote:

Exactly the reason to try and get p2p tcp to work through a behave
nat... it won't prevent these things from happening now, but hopefully
it can be avoided in the future.
I hope these p2p guys consider congestion control. The reference in 
the
slashdot article to udp file transfer explicitly calls out the need to
make the udp transfer tcp-friendly, which was at least somewhat 
reassuring.

-Jonathan R.

Dan Wing wrote:

My quick read is that folks are doing UDP-based file transfers 
because
peer-to-peer TCP doesn't work.  And we can expect UDP-based
implementations won't be TCP-friendly...  This seems ripe for net
meltdown considering the claimed percentage of TCP traffic that, 
today,
is p2p file sharing.

Director, Service Provider VoIP Architecture   Parsippany, NJ 
07054-2711

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Nov 2004 09:03:32 -0800 (PST)

On Wednesday, November 24, 2004, at 05:01 AM, nagendra modadugu wrote:
I wonder why no-one has suggested user-land TCP to be run over
UDP--
Along the lines of DCCP?

Melinda

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 09:26:29 -0800 (PST)

Will DCCP survive over my Linksys WRT54G?

-d

On Nov 24, 2004, at 9:03 AM, Melinda Shore wrote:

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Nov 2004 09:33:40 -0800 (PST)

On Wednesday, November 24, 2004, at 12:26 PM, Dan Wing wrote:
Will DCCP survive over my Linksys WRT54G?
Sure. although if you use it to transport application data
that includes payload-embedded addresses the usual caveats
apply.
Melinda

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 10:34:42 -0800 (PST)

On Nov 24, 2004, at 9:33 AM, Melinda Shore wrote:

On Wednesday, November 24, 2004, at 12:26 PM, Dan Wing wrote:
Will DCCP survive over my Linksys WRT54G?
Sure.
You're saying my Linksys WRT54G will see DCCP's IP protocol number (I 
don't see one listed at IANA's website, I guess because it isn't yet 
assigned by IANA) and the WRT54G will know to maintain a NAT binding 
based on the DCCP port numbers to allow bi-directional traffic -- just 
like UDP, TCP, and IPsec initiated by a PC behind the WRT54G.

I'm doubtful.

although if you use it to transport application data
that includes payload-embedded addresses the usual caveats
apply.
Sure, of course.  Which brings us back to the problem that started this 
thread -- using TCP for p2p file transfers.

-d

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Nov 2004 10:42:56 -0800 (PST)

On Wednesday, November 24, 2004, at 01:35 PM, Dan Wing wrote:
I'm doubtful.
If a NAT supports dccp it supports dccp.  There's nothing
inherently NAT-unfriendly about the protocol.
Melinda

---

From: [email-masked]
Date: Wed, 24 Nov 2004 10:56:16 -0800 (PST)

I think most residential routers do not understand DCCP and discard it
because DCCP is another transport layer protocol with another 'protocol
number'.

Besides getting p2p-TCP to work through NATs, we might want to look into
RUDP that IETF once explored in the past, and that implements
congestion&flow control like TCP.

http://www.ietf.org/proceedings/99mar/I-D/draft-ietf-sigtran-reliable-udp-00.txt
which was derived from RDP:
- rfc 980 (version 1)
- rfc 1151 (version 2),

Yutaka

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 11:04:54 -0800 (PST)

On Nov 24, 2004, at 10:42 AM, Melinda Shore wrote:

On Wednesday, November 24, 2004, at 01:35 PM, Dan Wing wrote:
I'm doubtful.
If a NAT supports dccp it supports dccp.  There's nothing
inherently NAT-unfriendly about the protocol.
I didn't mean to imply there was some NAT-unfriendliness in the 
protocol.

But DCCP doesn't, by itself, only provides TCP-friendliness.  It 
doesn't provide the other necessary features for p2p connectivity, 
namely (1) the ability to traverse existing NATs and (2) the ability 
for p2p connectivity when both hosts are behind NATs.

(2) could be solved with a STUN-like protocol.

I don't see an elegant solution to (1).

-d

---

From: nagendra modadugu <[email-masked]>
Date: Wed, 24 Nov 2004 12:04:21 -0800 (PST)

> "as-good-as-TCP" UDP-based protocol that someone will invent.

More bandwidth because of the extra UDP header?  Or are there
other reasons?

nagendra

---

From: Jon Ringle <[email-masked]>
Date: Wed, 24 Nov 2004 12:12:58 -0800 (PST)

> I don't see an elegant solution to (1).

In regards to to p2p tcp behind NATs, are you familiar with the NUTSS 
research:

http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf
http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf

This uses an approach that uses a STUN extension and SIP. For a 
"BEHAVE-compliant" NAT, the port prediction described is not necessary, since 
the port prediction is meant to try to deal with symmetric NATs.

Jon

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 14:27:15 -0800 (PST)

On Nov 24, 2004, at 12:04 PM, nagendra modadugu wrote:

TCP-over-UDP would use more bandwidth than TCP or a new
"as-good-as-TCP" UDP-based protocol that someone will invent.
-d
More bandwidth because of the extra UDP header?
Right.

-d

Or are there other reasons?

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 15:19:21 -0800 (PST)

On Nov 24, 2004, at 11:57 AM, Jon Ringle wrote:

In regards to to p2p tcp behind NATs, are you familiar with the NUTSS
research:
http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf
http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf
Yes, but I had forgotten about it.  Thanks for the pointer.

This uses an approach that uses a STUN extension and SIP. For a
"BEHAVE-compliant" NAT, the port prediction described is not 
necessary, since
the port prediction is meant to try to deal with symmetric NATs.
Remember that behave (draft-ietf-behave-nat) only defines UDP behavior,
not TCP behavior.  At the meeting in DC, it was agreed that the filename
would be modified to clearly indicate that it covers only UDP.
TCP behavior would be described in another document.  However, to my
knowledge, no one has stepped up to writing the TCP behavior document.
It appears that for p2p TCP to work, we need such a document and we
need testing, akin to Cullen's draft-jennings-midcom-stun-results, to
determine what TCP behavior exists for today's NATs.
-d

---

From: nagendra modadugu <[email-masked]>
Date: Wed, 24 Nov 2004 16:54:15 -0800 (PST)

> >More bandwidth because of the extra UDP header?

Not that I'm recommending userland TCP as a solution, but it's
likely to be better behaved than the schemes being designed
by the p2p folks (it took so many years for TCP implementations
to stabilize and generate friendly quantifyable flows).

I'd think that the client programming model will be a bigger
issue (handling all the timers in userland, that are otherwise
abstracted by the kernel, etc.), than the 8-byte UDP header overhead.

nagendra

---

From: Jon Ringle <[email-masked]>
Date: Wed, 24 Nov 2004 17:19:49 -0800 (PST)

> determine what TCP behavior exists for today's NATs.

You mean something like Saikat's work:
http://list.sipfoundry.org/archive/ietf-behave/msg00215.html

Jon

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 24 Nov 2004 19:27:58 -0800 (PST)

I think most residential routers do not understand DCCP and discard 
it
because DCCP is another transport layer protocol with another 
'protocol
number'.
I might have misunderstood the point of this thread, but this SEEMED 
to be the issue - since DCCP is another transport protocol (albeit one 
that hasn't made it to RFC yet), the cable modem with a builtin NAT 
you bought last week will look at the packet, decide it doesn't know 
what to do with Protocol 33 ("informally made available for 
experimental DCCP use", quoting the current draft), and drop the 
packets on the floor.

So the hope would be that TCP-over-UDP would pass unscathed through 
the same cable modem with a builtin NAT, because it's just dorking 
with the outermost UDP headers, and not noticing that the "application 
protocol" seems to be TCP.

If your cable modem with a builtin NAT doesn't think it's also an ALG, 
that could work. If you DO have a Very Helpful cable modem with a 
builtin NAT and ALG, the ALG will notice that the "application 
protocol" doesn't seem to be HTTP, SMTP, POP3, or some other 
widely-deployed TCP-based client-server protocol, and will ALSO drop 
the packets on the floor.

If I caught the drift.

Besides getting p2p-TCP to work through NATs, we might want to look 
into
RUDP that IETF once explored in the past, and that implements
congestion&flow control like TCP.

http://www.ietf.org/proceedings/99mar/I-D/draft-ietf-sigtran-reliable-udp-00.txt
which was derived from RDP:
- rfc 980 (version 1)
- rfc 1151 (version 2),
I am always eager to learn, but do not understand at this time why 
RUDP would be simpler than TCP over UDP, if the point is to pole-vault 
over a NAT that has UDP policies that we like better than its TCP 
policies.

At the very least, we should be clear on what we're trying to achieve. 
We threw DCCP into the discussion, but nobody explained why DCCP (with 
congestion avoidance but no transport-level retransmissions) would be 
a good protocol for file transfers (maybe we changed topics, but that 
WAS the subject of the thread I'm replying to!)...

Spencer

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 22:30:13 -0800 (PST)

I couldn't agree more.

However, when was the last time you met someone in the computer 
industry who didn't think they could Do Better?

-d

On Nov 24, 2004, at 4:54 PM, nagendra modadugu wrote:

-d

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 22:36:48 -0800 (PST)

On Nov 24, 2004, at 5:03 PM, Jon Ringle wrote:

This uses an approach that uses a STUN extension and SIP. For a
"BEHAVE-compliant" NAT, the port prediction described is not
necessary, since
the port prediction is meant to try to deal with symmetric NATs.
Remember that behave (draft-ietf-behave-nat) only defines UDP 
behavior,
not TCP behavior.  At the meeting in DC, it was agreed that the 
filename
would be modified to clearly indicate that it covers only UDP.

Yes, thanks.

The key, though, is to run that test against all of the NATs available 
at Circuit City, Fry's, Best Buy, and their EMEA and AsiaPac 
equivalents, and throw in a few NATs that are resold/leased by service 
providers in each of those markets, and publish the results.  With that 
we can spend efforts to solving the problems that are solvable by 
today's NATs.  For example, from Cullen's experiments we learned that 
symmetric NATs are a mostly-theoretical problem, and don't exist in 
quantity in the wild.

-d

---

From: Saikat Guha <[email-masked]>
Date: Thu, 25 Nov 2004 02:53:26 -0800 (PST)

> determine what TCP behavior exists for today's NATs.

I will volunteer for this. I have been testing NATs for TCP traversal
and have some preliminary data based on the 13 or so NATs that I could
find readily. I would like the opportunity to test it on both a wider
spectrum of NATs and on a distribution of NATs that represent market
penetration of the various models. Please contact me if you can donate
some computer time; the test client can be downloaded from
http://www.cs.cornell.edu/~saikat/NATs.html 

Ongoing test results are available at
http://www.cs.cornell.edu/~saikat/NAT-results.htm

-- 
Saikat
Attachment:
signature.asc

---

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Nov 2004 06:27:26 -0800 (PST)

On Wednesday, November 24, 2004, at 10:29 PM, Spencer Dawkins wrote:
At the very least, we should be clear on what we're trying to achieve. 
We threw DCCP into the discussion, but nobody explained why DCCP (with 
congestion avoidance but no transport-level retransmissions) would be 
a good protocol for file transfers (maybe we changed topics, but that 
WAS the subject of the thread I'm replying to!)...
It's not, particularly, but if the problem to be solved is a NAT-
friendly-ish transport protocol that doesn't misbehave on the network,
DCCP would probably be the closest of what's currently available.
That said, I'm not particularly a DCCP fan - I think the cost/benefit
tradeoff is kind of marginal in many cases.
Melinda

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 25 Nov 2004 11:40:48 -0800 (PST)

I have expressed my willingness to Cullen to spend some time to work on
the TCP behavior document..
Senthil

At 05:53 AM 11/25/2004 -0500, Saikat Guha wrote: