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

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 19 Jul 2007 09:43:17 +0300

[As Cullen pointed out, this is better located on MMUSIC. Thanks.]

On Thursday 19 July 2007 09:14:29 ext Juha Heinanen wrote:
> a while back i read ice tutorial slides and my impression was that the
> protocol was very complex (pity implementers) and provided only a bit
> better nat traversal capability than what [open]ser/rtpproxy/mediaproxy
> have been offering to lots of users for years already.

Media proxying is totally broken for a bunch of different reasons:

1/ Like many SIP ALGs - it screws the signaling when it does not understand 
something. Last time I tried OpenSER media proxying, TCP/COMEDIA sessions did 
not work at all (even with public unfirewalled IPs on both endpoints).

2/ At least mediaproxy implementation does not scale at all. It might be good 
if one's business consists of selling relay boxes. That's an implementation 
issue however.

3/ It is totally fatally insecure by design. It is trivial to DoS, or worse, 
hijack, a media flow by sending fake RTP probe packets to the relay.

> because of this (complexity, little added value), i doubt that full ice
> will be widely implemented or used.  i don't have any opinion on if ietf
> should publish the spec or not though, because there are already so many
> irrelevant rfcs out there that one more doesn't make any difference.

3/ ICE is secure: no voice hammer, no media hijacking.

2/ ICE scales well as it puts the hard work on the endpoints (and usage of 
TURN may be limited to worst cases).

1/ ICE does not screw up the SIP signaling, and you do not need to buy a SIP 
server upgrade to support the next SDP extension.

In all due fairness, simple hole punching also has advantages 1 and 2 over 
media relaying. And it is about as secure as SIP without any traversal 
mechanism, which is to say, less secure than ICE, but much more secure than 
media relaying.

Regards,

-- 
Rémi Denis-Courmont

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

---

From: Jan Janak <[email-masked]>
Date: Thu, 19 Jul 2007 14:29:25 +0200

> have been offering to lots of users for years already.

 The NAT traversal algorithm implemented in [open]ser, rtpproxy, and
 mediaproxy had been developed long before the first version of the ICE
 draft; at that time no other solution existed (except for preliminary
 STUN and TURN drafts), and we needed something to make it work; in
 addition to that NAT traversal support in UA was virtually non-existent
 back then.

 Having said that, it is true that the algorithm implemented in
 [open]ser is simpler than ICE, but I believe that these two cannot
 be directly compared. Even the NAT traversal logic in SER can get
 pretty complex if none of the end-points is a PSTN gateway in the
 public internet (especially if you want to handle re-INVITEs and
 serial forking properly).

   Jan.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 19 Jul 2007 16:45:59 +0200

> serial forking properly).

I don't think it is a question whether ICE is complex or not. The question
is if the complexity is worth it. An argumentation line one can choose is
the e2e principle which justifies the load of software loaded in the
end-devices (think for example of TCP) to gain reliability.

If ICE can accomplish the reliability promise, it also helps to migrate away 
from media relays (which is what SER does using rtpproxy) , which is a good thing.

So I think that the right course of action is that folks doubting ICE reliability
make their case (by that I mean specific arguments rather than emotional debates 
about red-colored nails and other hardware).

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: "David Barrett" <[email-masked]>
Date: Thu, 19 Jul 2007 11:05:57 -0700

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore
> LC for RFC
> 

Er, my "specific argument" is "until it's been proven to work, it hasn't
been proven to work".  It's tautological, but no less true for it.

Indeed, if you're *not* doubting ICE, why aren't you?

-david

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 21 Jul 2007 16:47:52 +0200

>Indeed, if you're *not* doubting ICE, why aren't you?

Hi David,

I'm not entirely sure what is the step you are suggesting?

I think ICE is architecturally right answer to the right problem.
Notwithstanding that, there are certainly some things I prefer
differently (e.g., the infamous debate about proactive hole punching)
or may turn out to be bugs. I think though that the key problem at
this point is of institutional nature. In the IETF language, "hasn't
been proven to work" is adequate to "lacking running code" and this
appears to be a phenomen which is indeed occuring in the IETF and
is not unique to ICE.

The question is how to get this fixed?

Some other standardization bodies enjoying the amount of contributions
and complexity as the IETF is enjoying now (S in SIP does not really
stand for Simple), proceed with 'after-fact filters', in that they
produce the initial specs faster and later produce 'profiles' which
separate what has proved and what less. Plus -bis versions are produced
for whatever appears worth puttting effort in it (i.e., for which there
is running code and field evidence of improvement need).This could be 
an approach  which may be more feasible in today's IETF's dimension than 
trying to get back to historical roots.

-jiri

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 21 Jul 2007 10:10:10 -0700

I fully agree with Jiri that this is an IETF problem and not an ICE
problem.
ICE-17 is a great document, no doubt about it.

What happens however of someone finds an innovative approach that may
work better? Will it be rejected because it will not be RFC standards
compliant?

What could an innovator tell customers about a solution that works
better but is not IETF ICE RFC standards compliant?

Henry

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]] 
Sent: Saturday, July 21, 2007 9:48 AM
To: David Barrett; 'Jan Janak'; 'Juha Heinanen'
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
deploymentdatabefore LC for RFC

At 20:05 19/07/2007, David Barrett wrote:
>> make their case (by that I mean specific arguments rather than
emotional
>> debates

Hi David,

-jiri 

_______________________________________________
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: Jiri Kuthan <[email-masked]>
Date: Mon, 23 Jul 2007 22:37:31 +0200

>work better? Will it be rejected because it will not be RFC standards

I don't think so, IETF is having a history of working on competing standards,
jabber and simple being a prominent and recent example thereof. I think that's
actually with current IETF's size and dynamics a fairly good strategy to
eliminate single points of failure. 

-jiri

---

From: "Adam Fisk" <[email-masked]>
Date: Tue, 24 Jul 2007 16:07:32 -0400

I've followed ICE development on the sidelines for years now, and I'm
currently implementing ICE 17.  I've implemented what will be open source
implementations of STUN and TURN, both client and server.  Here are the key
points I've taken away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to the
current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was
surprised at how hard it was, particularly for a draft that's so close to
becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost done"
state like used to happen in the Routing group.  I realize that's asking a
lot given how much work has gone into it and how eager everyone is to
finalize it.  I think the problem is that standardizing NAT traversal is
just hard, and hard problems are difficult to make simpler.  In my
implementation of ICE, I do think it could be done more simply, but I don't
have concrete suggestions right now because I'm still pulling my hair out
with the implementation.  I'm not talking about drastic changes anywhere,
but all the checklist fiddling sure takes a lot of patience to write.
Simplifications might just be in the description and not necessarily the
algorithm.

I think it's a hard enough and important enough problem that we owe it to
ourselves to be even more patient with an "almost done" state that adds the
final touches based on real-world feedback.  I don't doubt for a second that
ICE works, but it's so complex that I worry no one outside huge companies
will ever implement it.  That would be a huge hindrance to ICE's adoption
and power.

-Adam

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 24 Jul 2007 13:48:34 -0700

Adam,

I fully agree with your positive assessment of the ICE-17 document.

Do you by any chance plan to also develop a test tool for testing the
NAT environment and the success/failure cases, connection times, etc.,
to measure results?

Or maybe you know someone who does?

Thanks, Henry

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Fisk
Sent: Tuesday, July 24, 2007 3:08 PM
To: Jiri Kuthan
Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen;
[email-masked]; [email-masked]
Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
deploymentdatabefore LC for RFC

I've followed ICE development on the sidelines for years now, and I'm
currently implementing ICE 17.  I've implemented what will be open
source implementations of STUN and TURN, both client and server.  Here
are the key points I've taken away from that experience: 

1) The patience of Jonathan and everyone else in meticulously getting to
the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was
surprised at how hard it was, particularly for a draft that's so close
to becoming an RFC. 
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost
done" state like used to happen in the Routing group.  I realize that's
asking a lot given how much work has gone into it and how eager everyone
is to finalize it.  I think the problem is that standardizing NAT
traversal is just hard, and hard problems are difficult to make simpler.
In my implementation of ICE, I do think it could be done more simply,
but I don't have concrete suggestions right now because I'm still
pulling my hair out with the implementation.  I'm not talking about
drastic changes anywhere, but all the checklist fiddling sure takes a
lot of patience to write.  Simplifications might just be in the
description and not necessarily the algorithm. 

I think it's a hard enough and important enough problem that we owe it
to ourselves to be even more patient with an "almost done" state that
adds the final touches based on real-world feedback.  I don't doubt for
a second that ICE works, but it's so complex that I worry no one outside
huge companies will ever implement it.  That would be a huge hindrance
to ICE's adoption and power. 

-Adam

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 24 Jul 2007 23:25:04 +0200

At 22:07 24/07/2007, Adam Fisk wrote:
>I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.

That's marvellous news -- can you send me a pointer to that?

>  Here are the key points I've taken away from that experience: 
>
>1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
>2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC. 

All three points are wholeheartly easy to agree with. I would have added too
ICE is the "right" solution.

The question to me is whether Mr. Time and Mr. $ are not against us. That question
was asked couple of meetings ago by Spencer D. in an 'sbc bar bof' -- basically 
fingerpointing at the NAT experience, "right" solution (IPv6) and the outcome. 
The concern is that by time we have ICE, everyone will have the problem solved 
using media relays and mass economy will make it a more viable solution than anything 
else.

Future is generally hard to predict (that's why analysts like to predict past :-)),
so I think it would be at least a proper step to document current practices (media
relays) so that the IETF's picture stays grounded (whatever the risky comeout of work 
on "right" solutions may be.)

-jiri

---

From: "Ingemar Johansson S (LU/EAB)" <[email-masked]>
Date: Wed, 25 Jul 2007 01:22:32 +0200

Hi
 
I have been looking at the possibility to include the bandwidth modifiers from RFC3556 in SDPCapNeg or its companying media cap draft. 

As the whole configuration is not set until the potential configurations my interpretation is that the bandwidth modifiers must be put here.
If one look at draft-ietf-mmusic-sdp-media-capabilities page 6 one could imagine that the pcfg line(s) are modified in the direction

a=pcfg:1 m=1,3|4,3 t=1 a=1 pt=1:100,4:101,3:102 \
  b=1:[AS:64,RS:800,RR:2400],4:[AS... and so on
 (The '\' sign is a line continuation sign)

The extra stuff is added after the already existing pcfg info, cannot say how valid the syntax is but I hope the principle is visible, i.e that one can set bandwidths for each potential config. 

As I see it there is at least one consequence, namely that it is not possible to specify several different options for the transport capabilities in the same pcfg line as this may mean different bandwidth settings. The consequence may then be that one need to specify more pcfg lines.

Possibly kicking in open doors with this email, if so the reason is that the mailthreads are sometimes a pain to follow.

Comments are welcome.

Ingemar

*******************************************
Ingemar Johansson
Senior Research Engineer
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden
Tel: +46 (0)8 4043042
ECN: 850-43042
Mobile: +46 (0)730 783289
MSN: [email-masked]
*******************************************

---

From: Aki Niemi <[email-masked]>
Date: Wed, 25 Jul 2007 03:06:50 +0300

Hi Adam,

ext Adam Fisk wrote:
> done"
> state like used to happen in the Routing group.  

This is not how we're supposed to operate in the IETF. We determine when
something is good enough and publish it. It can be revised later. There
is no such thing as a perfect standard. Otherwise it would not be called
a standard.

And I am certain that actual implementors have all along been involved
in the development of the specifications. How many other implementors
would we have to give an opportunity to comment before publication?

> I realize that's asking a

There are a lot of other protocols that are complex. For instance, if I
were to start implementing something that required TLS, I would not
dream of starting the effort by implementing my own crypto library.

And just for this reason, I strongly believe that one of the keys to
success of ICE is the availability of good-quality, appropriately
licensed open source implementations, so I applaud your efforts. There
is also another FOSS effort, in which what some might call a "huge
company" has been involved:

http://www1.ietf.org/mail-archive/web/mmusic/current/msg06016.html

Cheers,
Aki

---

From: "Adam Fisk" <[email-masked]>
Date: Wed, 25 Jul 2007 10:00:21 -0400

We do plan on doing that eventually, Henry, but it will be awhile.  We're a
2 coder shop, so these things take us forever, but we will definitely do
that at some point.  It just might not be in 2007, honestly, so it would
likely be too late to be useful for the WG.

-Adam

On 7/24/07, Henry Sinnreich <[email-masked]> wrote:
> Do you by any chance plan to also develop a test tool for testing the NAT
> environment and the success/failure cases, connection times, etc., to
> measure results?
>
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Adam
> Fisk
> *Sent:* Tuesday, July 24, 2007 3:08 PM
> *To:* Jiri Kuthan
> *Cc:* Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; [email-masked];
> [email-masked]
> *Subject:* Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
> asking a lot given how much work has gone into it and how eager everyone is
> to finalize it.  I think the problem is that standardizing NAT traversal is

---

From: "Adam Fisk" <[email-masked]>
Date: Wed, 25 Jul 2007 10:15:11 -0400

Hi Aki-

> is no such thing as a perfect standard. Otherwise it would not be called

Understood.  It just sounded like a prudent approach -- more of a
"real-world beta".  The more I wrap my ahead around ICE-17, the more I
become convinced it is the right approach and "good enough."  The fact that
it's such a pain to implement made me think there must be possible
simplifications, but I have yet to be able to point to any concrete
suggestion.  So the draft's holding up strongly for me.

> dream of starting the effort by implementing my own crypto library.

Yes.  I think that's the key.  ICE is hard, and implementors have to realize
that going in.  I think it's mostly tricky because everything is so
ICE-specific.  There aren't a lot of "gimmes" in ICE where you read it and
think "oh, no problem, that's just like X RFC or draft"  -- things you can
just knock off without thinking too much about it.  As such, it takes
considerable coding patience and endurance to plow through.  But that's
fine.

> http://www1.ietf.org/mail-archive/web/mmusic/current/msg06016.html

Ah, great!  I had missed that.  I love Nokia's efforts in this area.
Thanks.

-Adam

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 25 Jul 2007 21:04:43 -0600

For those that may not know, another example of this is IAX2 which is
currently under review for publication by the IETF.  This protocol
clearly competes with SIP at least on some fronts.  It may be difficult
for new protocols to emerge, particularly with there is such huge
momentum behind one, but it can happen.

FM

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 2:38 PM
To: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICEdeploymentdatabefore
LC for RFC

>work better? Will it be rejected because it will not be RFC standards

I don't think so, IETF is having a history of working on competing
standards,
jabber and simple being a prominent and recent example thereof. I think
that's
actually with current IETF's size and dynamics a fairly good strategy to
eliminate single points of failure. 

-jiri

>>> So I think that the right course of action is that folks doubting
ICE
>>> reliability

---

From: "Adam Fisk" <[email-masked]>
Date: Thu, 26 Jul 2007 00:41:14 -0400

I had a conversation earlier tonight at the NYC p2p meetup that led me to
question my previous assumptions about ICE "working".  Supposedly many
routers start to do funny things when they see lots of ICE UDP packets
flying by and trying lots of candidates.

This has me worried.  We all know the frightening number of NAT
configurations out there.  Maybe I missed it, but is there a test matrix
somewhere of NAT combinations and their success rates with ICE?  If not,
could we create one using one of the open source ICE implementations out
there (mine's not quite ready)?  I'd be happy to contribute my own router if
we had a simple test program, maybe based on the work at Nokia.

I think performing those simple tests would set everyone's mind at ease.
Otherwise, I am concerned that some NAT and firmware combinations would balk
at what they see as packet floods.

To a person, everyone I've talked to who has implemented this stuff in the
"real world" has said the array of problems with specific NAT configurations
is much more significant than they realized at first.  I think this is the
central problem -- the world we're deploying this in is much more chaotic
than that of more RFCs, as the BEHAVE group is trying to address.

-Adam

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 26 Jul 2007 04:09:54 -0700

This insight may be very useful when designing a test tool for ICE. 

As I have insisted, we need deployment testing for ICE and continued
tweaking to make it real.

I have no idea what the deployment testing may reveal and the attached
is a welcome example.

Is anyone on these lists designing a test tool for NAT scenario
discovery and for ICE?

Henry

Sent: Wednesday, July 25, 2007 11:41 PM

I had a conversation earlier tonight at the NYC p2p meetup that led me
to question my previous assumptions about ICE "working".  Supposedly
many routers start to do funny things when they see lots of ICE UDP
packets flying by and trying lots of candidates. 

This has me worried.  We all know the frightening number of NAT
configurations out there.  Maybe I missed it, but is there a test matrix
somewhere of NAT combinations and their success rates with ICE?  If not,
could we create one using one of the open source ICE implementations out
there (mine's not quite ready)?  I'd be happy to contribute my own
router if we had a simple test program, maybe based on the work at
Nokia. 

I think performing those simple tests would set everyone's mind at ease.
Otherwise, I am concerned that some NAT and firmware combinations would
balk at what they see as packet floods.

To a person, everyone I've talked to who has implemented this stuff in
the "real world" has said the array of problems with specific NAT
configurations is much more significant than they realized at first.  I
think this is the central problem -- the world we're deploying this in
is much more chaotic than that of more RFCs, as the BEHAVE group is
trying to address. 

-Adam

-Adam

---

From: Philip Matthews <[email-masked]>
Date: Thu, 26 Jul 2007 09:00:35 -0500

Have these people implemented the pacing stuff that is in ICE?  This  
behavior is why ICE has this pacing stuff.

- Philip

On 25-Jul-07, at 23:41 , Adam Fisk wrote:

> I had a conversation earlier tonight at the NYC p2p meetup that led  
> me to question my previous assumptions about ICE "working".   
> Supposedly many routers start to do funny things when they see lots  
> of ICE UDP packets flying by and trying lots of candidates.
>
> configurations out there.  Maybe I missed it, but is there a test  
> matrix somewhere of NAT combinations and their success rates with  
> ICE?  If not, could we create one using one of the open source ICE  
> implementations out there (mine's not quite ready)?  I'd be happy  
> to contribute my own router if we had a simple test program, maybe  
> based on the work at Nokia.
>
> I think performing those simple tests would set everyone's mind at  
> ease.  Otherwise, I am concerned that some NAT and firmware  
> combinations would balk at what they see as packet floods.
>
> To a person, everyone I've talked to who has implemented this stuff  
> in the "real world" has said the array of problems with specific  
> NAT configurations is much more significant than they realized at  
> first.  I think this is the central problem -- the world we're  
> deploying this in is much more chaotic than that of more RFCs, as  
> the BEHAVE group is trying to address.
>
> -Adam
>
>
> I've followed ICE development on the sidelines for years now, and  
> I'm currently implementing ICE 17.  I've implemented what will be  
> open source implementations of STUN and TURN, both client and  
> server.  Here are the key points I've taken away from that experience:
>
> 1) The patience of Jonathan and everyone else in meticulously  
> getting to the current draft is astonishing.
> 2) ICE is complex as hell and a pain in the ^#* to implement.  I  
> was surprised at how hard it was, particularly for a draft that's  
> so close to becoming an RFC.
> I like Phillip's earlier suggestion that the draft stay in the  
> "almost done" state like used to happen in the Routing group.  I  
> realize that's asking a lot given how much work has gone into it  
> and how eager everyone is to finalize it.  I think the problem is  
> that standardizing NAT traversal is just hard, and hard problems  
> are difficult to make simpler.  In my implementation of ICE, I do  
> think it could be done more simply, but I don't have concrete  
> suggestions right now because I'm still pulling my hair out with  
> the implementation.  I'm not talking about drastic changes  
> anywhere, but all the checklist fiddling sure takes a lot of  
> patience to write.  Simplifications might just be in the  
> I think it's a hard enough and important enough problem that we owe  
> it to ourselves to be even more patient with an "almost done" state  
> that adds the final touches based on real-world feedback.  I don't  
> doubt for a second that ICE works, but it's so complex that I worry  
> no one outside huge companies will ever implement it.  That would  
> be a huge hindrance to ICE's adoption and power.
>
> -Adam
>
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Jul 2007 13:14:35 -0500

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Thursday, July 26, 2007 6:10 AM
> To: Adam Fisk; Jiri Kuthan
> Cc: [email-masked]; [email-masked]; Juha Heinanen; Jan 
> Janak; P2PSIP WG
> deploymentdatabefore LCfor RFC
> 
> As I have insisted, we need deployment testing for ICE and 
> continued tweaking to make it real.
> 
> I have no idea what the deployment testing may reveal and the 
> attached is a welcome example.
> 
>  
> 
> Is anyone on these lists designing a test tool for NAT 
> scenario discovery and for ICE?

Awhile back Christian Huitema announced Microsoft's NAT testing
tool,
http://www1.ietf.org/mail-archive/web/behave/current/msg02117.html

    >
    >  Microsoft just released a tool that may be interesting for
    >  this list:
    >  http://www.microsoft.com/windows/using/tools/igd/default.mspx
    >  The tool applies various tests against routers to check
    >  how they implement NAT, UPNP, or support of various TCP
    >  options. It is based on Microsoft's "home networking"
    >  requirements for XP and Vista. Arguably, a later version
    >  could implement BEHAVE's requirement, when they are
    >  published by the IETF.
    >
    >  -- Christian Huitema
    >

It requires a browser that supports Active X.

-d

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Adam Fisk
> I had a conversation earlier tonight at the NYC p2p meetup 
> that led me to question my previous assumptions about ICE 
> "working".  Supposedly many routers start to do funny things 
> when they see lots of ICE UDP packets flying by and trying 
> lots of candidates. 
> 
> This has me worried.  We all know the frightening number of 
> NAT configurations out there.  Maybe I missed it, but is 
> there a test matrix somewhere of NAT combinations and their 
> success rates with ICE?  If not, could we create one using 
> one of the open source ICE implementations out there (mine's 
> not quite ready)?  I'd be happy to contribute my own router 
> if we had a simple test program, maybe based on the work at Nokia. 
> 
> I think performing those simple tests would set everyone's 
> mind at ease.  Otherwise, I am concerned that some NAT and 
> firmware combinations would balk at what they see as packet floods.
> 
> To a person, everyone I've talked to who has implemented this 
> stuff in the "real world" has said the array of problems with 
> specific NAT configurations is much more significant than 
> they realized at first.  I think this is the central problem 
> -- the world we're deploying this in is much more chaotic 
> I've followed ICE development on the sidelines for years now, 
> and I'm currently implementing ICE 17.  I've implemented what 
> will be open source implementations of STUN and TURN, both 
> client and server.  Here are the key points I've taken away 
> from that experience: 
> 
> 2) ICE is complex as hell and a pain in the ^#* to implement. 
>  I was surprised at how hard it was, particularly for a draft 
> that's so close to becoming an RFC. 
> I like Phillip's earlier suggestion that the draft stay in 
> the "almost done" state like used to happen in the Routing 
> group.  I realize that's asking a lot given how much work has 
> gone into it and how eager everyone is to finalize it.  I 
> think the problem is that standardizing NAT traversal is just 
> hard, and hard problems are difficult to make simpler.  In my 
> implementation of ICE, I do think it could be done more 
> simply, but I don't have concrete suggestions right now 
> because I'm still pulling my hair out with the 
> implementation.  I'm not talking about drastic changes 
> I think it's a hard enough and important enough problem that 
> we owe it to ourselves to be even more patient with an 
> "almost done" state that adds the final touches based on 
> real-world feedback.  I don't doubt for a second that ICE 
> works, but it's so complex that I worry no one outside huge 
> companies will ever implement it.  That would be a huge 
> hindrance to ICE's adoption and power. 
> 
> -Adam
> 
>  
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Jul 2007 13:15:10 -0500

> From: Adam Fisk [mailto:[email-masked]] 
> Cc: Jan Janak; Juha Heinanen; David Barrett; [email-masked]

*Routers*?  Or NATs?  Routers don't maintain state and thus
aren't aware of new flows or old flows; I would be surprised
of this happening and would be very interested in hearing more
about it.  I suppose all sorts of packet-optimization boxes,
network scanning detectors, and intrusion prevention devices
might perceive a bunch of ICE probes as a network scanner.

> success rates with ICE? 

No, partially because it's terribly difficult -- if not flat-out
impossible -- to emperically test a NAT and determine how its
internal code operates (filtering behavior and port mapping
behavior).

> If not, could we create one using 

There is Microsoft's Active X-based test, see
http://www1.ietf.org/mail-archive/web/behave/current/msg02117.html

But I'm not aware of anything for ICE; ICE doesn't care what
'kind' of NAT you have, it just tries to get connectivity.  

Having statistics with ICE would be valuable and would be useful.

> firmware combinations would balk at what they see as packet floods.

Some NATs do balk at new UDP flows being initiated quickly and
cannot keep up with such new flows.  This is described in section
B.1 of draft-ietf-mmusic-ice-17, and this is why ICE paces its
checks 20ms apart.

> than that of more RFCs, as the BEHAVE group is trying to address. 

I fully agree that BEHAVE's documents will not make the problem
go away.  Like anything (TCP implementation, RTP implementation), 
a NAT might or might not adhere to the RFCs created by the BEHAVE
working group.

-d

> 	I've followed ICE development on the sidelines for 
> years now, and I'm currently implementing ICE 17.  I've 
> implemented what will be open source implementations of STUN 
> and TURN, both client and server.  Here are the key points 
> I've taken away from that experience: 
> 	
> 	1) The patience of Jonathan and everyone else in 
> meticulously getting to the current draft is astonishing.
> 	2) ICE is complex as hell and a pain in the ^#* to 
> implement.  I was surprised at how hard it was, particularly 
> for a draft that's so close to becoming an RFC. 
> 	I like Phillip's earlier suggestion that the draft stay 
> in the "almost done" state like used to happen in the Routing 
> 	I think it's a hard enough and important enough problem 
> that we owe it to ourselves to be even more patient with an

---

From: "Adam Fisk" <[email-masked]>
Date: Thu, 26 Jul 2007 14:40:07 -0400

I have to get the contact information for the developer who I talked to
about it, but I'll hopefully track him down.  He's the lead developer for
Civil Netizen.  I'll post to the list anything I discover.

It's good to hear the pacing behavior in ICE is designed to address this.
Do you know approximately what draft introduced that?

Thanks.

-Adam

On 7/26/07, Philip Matthews <[email-masked]> wrote:
> > to ourselves to be even more patient with an "almost done" state that adds
> > the final touches based on real-world feedback.  I don't doubt for a second
> > that ICE works, but it's so complex that I worry no one outside huge
> > companies will ever implement it.  That would be a huge hindrance to ICE's
> > adoption and power.
> >
> > -Adam
> >
> >
> >

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 26 Jul 2007 16:13:19 -0400

The issue on whether to include the bandwidth parameter (incl. RTCP bw 
modifiers) in the core was discussed the MMUSIC session yesterday. There 
was no clear consensus, except that Magnus will take another look at-it, 
and come up with some motivational use cases in the next 2 weeks. Based 
on those, the WG will then decide whether this is a problem that needs 
to be addressed in the core or not.

As to the specifics of how we would do that, I'd probably do it 
differently (more in line with the current 
capability-reference-by-number strategy), but let's hold off on that 
part of the discussion.

Thanks

-- Flemming

---

From: "Adam Fisk" <[email-masked]>
Date: Thu, 26 Jul 2007 16:51:58 -0400

On 7/24/07, Jiri Kuthan <[email-masked]> wrote:
> implementations of STUN and TURN, both client and server.
>

We're not quite public yet, Jiri.  I'll send a note to the list when we're
up, though.

-Adam

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Jul 2007 16:01:01 -0500

...
> It's good to hear the pacing behavior in ICE is designed to 
> address this.  Do you know approximately what draft introduced that?

The first mention in ICE that I see of the per-transaction pacing was 
in ICE-06, http://tools.ietf.org/html/draft-ietf-mmusic-ice-06, 
published October 2005.

As I recall, this was added because NAT testing showed it was 
necessary.

-d

---

From: "David Barrett" <[email-masked]>
Date: Sun, 29 Jul 2007 18:00:28 +0100

_____  

From: [email-masked] 
Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC
for RFC

I'm not sure that matrixing out connectivity through NAT models is the right
approach.  Every NAT has a hundred ways to be configured (and
misconfigured), and generally at least two of them sit between most client
pairs.  The number of real-world permutations is astronomical, and it almost
certainly won't catch the weird cases that can and do happen with surprising
frequency.

A recent example is the bizarre NAT I mentioned before that duplicates every
packet sent 3-7 times (at the "It's A Grind" coffeeshop on Polk St in San
Francisco).  I've also dealt with the Google WiFi network (in Union Square,
San Francisco), which has the unusual property of only being able to receive
UDP from exactly *one* remote host per port - so you can send from a UDP
port to anywhere in the world just fine (with symmetric behavior), but you
can only receive back from the first - all other responses are blocked.

These are just two that I've personally experienced and that come up from
recent memory: I've seen even more unusual behavior I can't even begin to
explain in my users' logs.  I'd suggest that the only way to test ICE (or
any other NAT-traversal implementation) is to actually run it on thousands
of computers hosted behind real-world network connections and see how well
it works.

I can't overstress how unusual, slow, unpredictable, and unreliable the
internet can get in the real world, and how making thing works in the real
world is far more difficult than making it work on paper.  The faster you
embrace real-world, large-scale testing, the faster you have something that
works outside the lab.

-david

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 29 Jul 2007 15:04:09 -0700

*       I'd suggest that the only way to test ICE (or any other
NAT-traversal implementation) is to actually run it on thousands of
computers hosted 

*       behind real-world network connections and see how well it works.

I fully agree and to make this work we need some tools that folks like
here in the IETF WGs can download and report back the results.

The requirements for such a NAT testing tool would make a nice I-D on
the condition someone is willing to write the code and make it available
on a web site, similar to most beta testing sites, say in this case DSL
Reports - > Speed Tests.

Thanks, Henry

From: David Barrett [mailto:[email-masked]] 
Sent: Sunday, July 29, 2007 12:00 PM
To: 'Adam Fisk'; 'Jiri Kuthan'
Cc: Henry Sinnreich; 'Jan Janak'; 'Juha Heinanen'; [email-masked]
Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
deploymentdatabefore LC for RFC

From: [email-masked] 

I'm not sure that matrixing out connectivity through NAT models is the
right approach.  Every NAT has a hundred ways to be configured (and
misconfigured), and generally at least two of them sit between most
client pairs.  The number of real-world permutations is astronomical,
and it almost certainly won't catch the weird cases that can and do
happen with surprising frequency.

A recent example is the bizarre NAT I mentioned before that duplicates
every packet sent 3-7 times (at the "It's A Grind" coffeeshop on Polk St
in San Francisco).  I've also dealt with the Google WiFi network (in
Union Square, San Francisco), which has the unusual property of only
being able to receive UDP from exactly *one* remote host per port - so
you can send from a UDP port to anywhere in the world just fine (with
symmetric behavior), but you can only receive back from the first - all
other responses are blocked.

These are just two that I've personally experienced and that come up
from recent memory: I've seen even more unusual behavior I can't even
begin to explain in my users' logs.  I'd suggest that the only way to
test ICE (or any other NAT-traversal implementation) is to actually run
it on thousands of computers hosted behind real-world network
connections and see how well it works.

I can't overstress how unusual, slow, unpredictable, and unreliable the
internet can get in the real world, and how making thing works in the
real world is far more difficult than making it work on paper.  The
faster you embrace real-world, large-scale testing, the faster you have
something that works outside the lab.

-david

---

From: "Adam Fisk" <[email-masked]>
Date: Sun, 29 Jul 2007 19:37:37 -0400

I lost your message in the shuffle, Dan, so apologies for the delay.

> might perceive a bunch of ICE probes as a network scanner.

Sorry -- NATs.  I believe he was talking about the kind of issues discussed
in B.1.  I've unfortunately been unable to get back in touch with the
developer, but I suspect he implemented a much earlier ICE draft and
abandoned it.  That's the impression I got, so hopefully it's the case and
he abandoned a version from before the pacing was introduced.

Thanks Dan.

-Adam

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Jul 2007 16:53:58 -0700

> Sorry -- NATs.  I believe he was talking about the kind of 
> issues discussed in B.1.  I've unfortunately been unable to 
> get back in touch with the developer, but I suspect he 
> implemented a much earlier ICE draft and abandoned it.  
> That's the impression I got, so hopefully it's the case and 

I would like to hear any more detail you might have.  This behavior
has echos of some issues that Phil Zimmermann and Alan Johnston 
mentioned they had seen during their development of ZRTP.  However,
I don't recall any details about the beginning-of-UDP-flow packet
loss they were seeing; perhaps it was also across these same sort
of NATs.

-d

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 31 Jul 2007 17:22:46 -0700

I am starting to wonder if this is a moot discussion since large
providers install SBC on all customers facing links.

The tendency of the SBC may to just route the SIP message to their own
SIP proxy, who will just discard SIP messages from sources it does not
know.

Do you have any information on this?

Thanks, Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2007 6:54 PM
To: 'Adam Fisk'
Cc: 'Jiri Kuthan'; 'Juha Heinanen'; 'Jan Janak'; [email-masked]; 'David
Barrett'
Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
deploymentdatabeforeLCfor RFC

-d