Subject: [P2PSIP] RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC

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

________________________________

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

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

On 7/24/07, Adam Fisk <[email-masked]> 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.  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

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

---

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

> -----Original Message-----
> 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
> Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE 
> 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 
> 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
> 
>  
> 
>