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

"Spencer Dawkins" <spencer@mcsr-labs.org> Thu, 25 November 2004 03:27 UTC

From: Spencer Dawkins <spencer@mcsr-labs.org>
Date: Wed, 24 Nov 2004 19:27:58 -0800
Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers
In-Reply-To: <E715BCC8-3E3E-11D9-95FC-000A95E35274@cisco.com>
Message-ID: <1d6e01c4d29e$e85b4da0$90878182@DFNJGL21>
MIME-Version: 1.0
Content-Type: text/plain

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