Subject: Re: [BEHAVE] Degree of compatibility of BitTorrent with endpoint-independent mapping?

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 03 Jun 2008 14:25:35 -0400

Iljitsch van Beijnum wrote:
> On 26 mei 2008, at 22:32, Bruce Lowekamp wrote:
> 
>> To the best of my knowledge (and I have not studied BitTorrent
>> implementations extensively), they don't try to make any allowances for
>> NAT behavior because there are enough hosts for which that is not an
>> issue that the applications work if they try enough connections.
> 
> No, that's not exactly true. In practice, you get much lower download 
> speeds with BitTorrent if you can't accept incoming connections. So 
> (some) clients implement UPnP and NAT-PMP to open up ports for incoming 
> sessions in the NAT, if present. It's also very common for BitTorrent 
> users to set up a mapping manually.
> 
> So BitTorrent does often use NAT traversal, just not with any of the 
> mechanisms that the IETF is familiar with.  :-)
> 

You're right, I was thinking about techniques other than NAT control.

More importantly, though, neither of those techniques work with 
multi-level NATs (or NATs on the other side of routers), so aren't 
really appropriate for the problem domain we're talking about here, as I 
understand it.  Now I suppose we could work more on extensions to NAT 
control protocols, but I don't know if those would be well received in 
the ISP space.  I wasn't involved in the midcom wg.  Maybe things have 
changed, though...

>> If NATs become even more common than they are now, BitTorrent
>> applications may need to do more NAT traversal, so then TCP-SO would be
>> more important.
> 
> I don't see simultaneous open happen for BitTorrent very soon. They may 
> switch to UDP instead.
> 

I suspect that if it worked reliably, it would be used.

Bruce
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Saikat Guha" <[email-masked]>
Date: Tue, 3 Jun 2008 20:49:53 +0200

> I suspect that if it worked reliably, it would be used.

FWIW, the stumbling block of using TCP traversal per Bram Cohen was
the active signaling plane (where the tracker would have to relay the
ICE or equiv. messages). UDP traversal is simpler in that (for many
NATs -- NB=I, EF=I) once you punch one hole, you can keep that hole
open indefinitely and publish the hole address in the tracker.

If someone can implement a BT tracker that performs the ICE relaying
at scale, I am sure BT clients would switch in a heartbeat.

-- 
Saikat

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 Jun 2008 23:39:03 +0200

On 3 jun 2008, at 20:25, Bruce Lowekamp wrote:

>> So BitTorrent does often use NAT traversal, just not with any of  
>> the mechanisms that the IETF is familiar with.  :-)

> really appropriate for the problem domain we're talking about here,  
> as I understand it.  Now I suppose we could work more on extensions  
> to NAT control protocols, but I don't know if those would be well  
> received in the ISP space.  I wasn't involved in the midcom wg.   
> Maybe things have changed, though...

I was just explaining how BitTorrent is commonly used, not how it  
would work in a world with multiple layers of NAT (something that we  
should avoid, anyway).

If I understand the endpoint independent mapping rationale correctly,  
the idea is that once a host uses a session using a certain source  
port, then the NAT will map that internal source port into an external  
source port and after that forward incoming sessions towards the  
external port to the internal host. BitTorrent applications could  
easily be modified to take advantage of that behavior. The side effect  
would be that they no longer use up excessive amounts of port numbers,  
so this would be win-win.

>> I don't see simultaneous open happen for BitTorrent very soon. They  
>> may switch to UDP instead.

> I suspect that if it worked reliably, it would be used.

The current situation works quite well, as people are attributing more  
than half of all internet traffic to BitTorrent and friends, so there  
was no real need to change anything, until Comcast started sending  
fake TCP resets for BitTorrent sessions. Using UDP transport could  
help against that.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Adam Fisk" <[email-masked]>
Date: Wed, 25 Jun 2008 23:40:50 -0400

IMU understanding BitTorrent doesn't formally support any NAT
traversal -- one of its many weak points.  Most clients rely on UPnP
or PMP as someone else mentioned.  Some clients support their own NAT
traversal implementations (Azureus, I believe, for example), but none
of those interoperate with other clients to my knowledge.  I've
definitely never heard of any client using TCP-SO.

See:
http://www.bittorrent.org/beps/bep_0000.html

-Adam

-- 
http://www.littleshoot.org
Open Source, Open Standards, Open Data
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave