Subject: [P2PSIP] RE: [BEHAVE] Re: ICE deployment data before LC for RFC

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 18 Jul 2007 12:20:22 -0700

Dan,

What you say makes sense but there is a lingering suspicion that after
admitting that RFC 3489 (STUN), RFC 4091, 4092 (ANAT), etc. just don't
work is that such paper evaluations are in no way a replacement for
proof and measurements. We still need an explanation why the right
approach cannot be taken:

* Publish open source code at Sourceforge.net or similar,
* Publish a test tool as well,
* Gather and publish the results, possibly involving SIPit or another,
* Perfect the OS code and the protocol until it works OK.

This has been done for "Hole Punching for P2P" in 
http://www.brynosaurus.com/pub/net/p2pnat/ 

What if ICE proves to be no better than its predecessors? 

So how can one compare something that has tools, measured and published
results with something like ICE that we have to take on pure faith?

My assumption is that hole punching is much more effective for P2PSIP
and I have copied the P2PSIP WG on this. The ratio of messages is
probably 5:1 or higher for ICE vs. hole punching and this is critical
when routing a P2PSIP message over an overlay in 5-10 hops. Of course I
cannot prove it since as yet ICE cannot be measured.

Let's do ICE the right way, there is too much at stake here.

Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 1:19 PM
To: Henry Sinnreich; 'Magnus Westerlund'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC

> The excellent I-D <draft-ietf-sipping-nat-scenarios-07> shows 
> the ICE call flow with two endpoints behind two NAT (Fig. 22 
> on page 38) require 66 messages just for the SIP INVITE!
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce
> narios-07.txt 

That figure does not show 66 messages.

That figure is clearly showing how the STUN messages are NATted,
which leads to an incorrect conclusion around the number of 
messages.  Specifically, for example, it shows this message
exchange which might be counted as "four messages"; yet, there
are only two messages (the allocate request and the allocate
response), which are NATted:

   L               NAT             STUN              
                                   Server
   |                |                |               
   |(1) Alloc Req   |                |               
   |Src=L-PRIV-1    |                |               
   |Dest=STUN-PUB-1 |                |               
   |--------------->|                |               
   |                |                |               
   |                |(2) Alloc Req   |               
   |                |Src=L-NAT-PUB-1 |               
   |                |Des=STUN-PUB-1  |               
   |                |--------------->|               
   |                |                |               
   |                |(3) Alloc Resp  |               
   |                |<---------------|               
   |                |Src=STUN-PUB-1  |               
   |                |Dest=L-NAT-PUB-1|               
   |                |Map=L-NAT-PUB-1 |               
   |                |Rel=STUN-PUB-2  |               
   |                |                |               
   |(4) Alloc Resp  |                |               
   |<---------------|                |               
   |Src=STUN-PUB-1  |                |               
   |Dest=L-PRIV-1   |                |               
   |Map=L-NAT-PUB-1 |                |               
   |Rel=STUN-PUB-2  |                |               
   |                |                |               

If we added another NAT on that path, the number of messages
on the network does not double.  The number of messages on 
the network stays the same -- the messages merely have their
IP and UDP headers rewritten by the NATs.  That NAT function
does not increase the number of messages on the network.

Similarly, another message shown in that same figure is also
one message; however, it's shown as two messages:

L               NAT             STUN              NAT               R
                                Server
|(9) SIP INVITE  |                |                |                |
|------------------------------------------------->|                |
|                |                |                |(10) SIP INVITE |
|                |                |                |--------------->|

As you know, there aren't two messages -- it's one message that is
NATted.

If message 9 and 10 were shown as clearly as messages 1-4, messages
9-10 would be shown as four messages (one from L to its NAT, another 
from NAT to NAT, and the forth (shown) from NAT to R).  But this is
just one SIP message, which is NATted.  It is inaccurate  to count
it as two separate messages or as four separate messages, because
it is only one packet that is NATted.  Counting a STUN packet,
or a DNS packet, as a separate message each time it traverses a 
NAT is similarly inaccurate.

By my count, figure 22 exchanges 24 STUN/ICE messages and 6 
SIP messages.

> What happens if the two endpoints are in different ISPs that 
> have NAT of their own in addition to the ones in Fig. 22?

The same 24 STUN/ICE messages would be exchanged, and the same
6 SIP messages would be exchanged.

> What happens if one would try ICE along a P2PSIP route with 
> say 5-8 hops?

The SIP signaling messages would traverse those 5-8 additional 
hops between the P2PSIP nodes participating in the SIP proxy
overlay.  The STUN/ICE messages are sent peer-to-peer, and 
would remain the same 24 messages if you're doing the same 
Figure 22 flow.  

> Would there be hundreds of messages?

No.

-d

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 18 Jul 2007 12:42:57 -0700

Francois,

> Heuh, no. This is just "exploratory concept" stuff, certainly not an 
> interoperable protocol specification.

I am happy to report we are in total agreement.

Henry

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 2:38 PM
To: Henry Sinnreich; Dan Wing; Magnus Westerlund
Cc: [email-masked]; [email-masked]; [email-masked]; Philip Matthews;
[email-masked]
Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC

> http://www.brynosaurus.com/pub/net/p2pnat/ 

Heuh, no. This is just "exploratory concept" stuff, certainly
not an interoperable protocol specification.

And if the proponents of this alternative hole punching didn't 
propose a draft at IETF when we starting working on this back
in 2001, it seems to me that it's too late.

> My assumption is that hole punching is much more effective 
> for P2PSIP and I have copied the P2PSIP WG on this. The ratio 
> of messages is probably 5:1 or higher for ICE vs. hole 
> punching and this is critical when routing a P2PSIP message 
> over an overlay in 5-10 hops. Of course I cannot prove it 
> since as yet ICE cannot be measured.

Well, your assumption may be wrong, especially in the absence of
a specification for this alternative hole punching technique.

The other thing I find funny in here is that the alternative 
hole punching techique as described on the web site uses a
centralize server common to BOTH ends to relay the address, while
ICE does not (i.e., each end can use their own STUN server).

In other words, the major difference between ICE and the
alternative-hole-
punching technique seems to be that alternative-hole-punching
assumes both ends use the same STUN server, which makes the 
rest of the exchange simpler (the "magic box" architectural
concept is always handy).

Ironically, this seems to me to be LESS usable in a global network
where you wont't use centralize servers, especially for p2psip.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Jul 2007 14:38:09 -0500

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 18 Jul 2007 15:05:13 -0600

> where you wont't use centralize servers, especially for p2psip.

This may be sufficient, but I don't think its necessary.  Each UA
punches the hole (and keeps it open, as David described) to whatever
STUN server they like, all that's required is that each server have the
same view of each client.  That is somewhat less restrictive.  In the
common case of the open Internet, as long as the STUN servers used by
each respective UA are in the "open", they don't have to be the same.
After that, the "public" or "visible" IP address/port is put in the
Contact headers.

Regarding the 90% coverage, this is what I'm referring to when I say
that it may be preferable to influence the NAT vendors to not do the
things that put them in the 10% cases.  I sort of thought that was what
the NAT guidelines draft was for.

In addition, if we are standardizing a protocol based on the 10% cases
and imposing potentially huge costs on the 90% to do so, then our
approach is incorrect.  We should be designing for the 90% case and
handling the 10% as exceptional behavior, i.e. a solution where you pay
the big cost only in the case where you are actually in the 10%.

FM