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

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 19 Jul 2007 11:36:43 -0700 (PDT)

Magnus,

The discussion thread started on the BEHAVE list. I believe, My comments are
also relevant to BEHAVE list. SO, I am including BEHAVE list to this thread.
Please see my comments inline below. Thanks.

regards,
suresh

--- Magnus Westerlund <[email-masked]> wrote:

> Dropping all lists but MMUSIC!
> 
> Pyda Srisuresh skrev:
> > Thanks to Henry and Frank for so eloquently articulating this. 
> > 
> > As both Henry and Frank mentioned, I fully support standardizing on HOLE
> > PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence to
> force
> > NAT vendors to migrate towards implementations that are friendly to Hole
> > Punching and the Application developers to design applications using the
> hole
> > punching techniques. That should be the FIRST order of priority. 
> > 
> > Yet, what is happening in BEHAVE WG is the other way around. Some people
> have
> > put their weight so heavily in favor of ICE that they asked to drop the
> work on
> > hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT
> > Traveral application design guidelines" as BEHAVE WG milestone.
> > 
> > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING
> TECHNIQUES
> > to move forward as a WG item?
> 
> I would like to remind people about a few things. ICE was request to 
> become a MMUSIC WG item in Vienna, that is FOUR years ago! The people 
> present supported that. During these years ICE has been rebaked several 
> times. People have provided input about a number of things; traversal 
> cases that didn't work, different forms of complexity, signalling usage.
> 
> During these 4 years anyone have had the possibility to influence the 
> process, including standing up saying that we should forget about the 
> maximum reliability for the sake of simplicity. But the consensus in 
> this discussion has remained that reliabilty is important. And I also 
> think the changes has shown that one has tried all the tricks that has 
> been thought of try to reduce the complexity of ICE. But as I think most 
> of you agree on, NAT traversal is problematic and simple solution 
> doesn't always work. We are today at state where we don't know know how 
> to make things simpler without sacrificing functionality.
> 
> There also has been discussion about if there should be multiple 
> solutions etc. But, to my knowledge the consensus also there has been 
> that one solution is the way to go.
> 
[suresh] I have not been part of the discussion pertaining to the merit of
multiple solutions vs single soultions. This may have been discussed in the
context of SIP and NAT traversal. So, I cant comment on this.

But, let me reiterate that HOLE PUNCHING TECHNIQUES have been around longer
than ICE. The techniques are generic and applicable to application traversal in
general. Kegel's work on UDP is the first published work on UDP hole punching.
USENIX paper by Bryan, Kegel and myself is the first work on TCP hole punching.
ford-behave-app draft is the first draft that I know if that describes the BCP
design practicies for P2P applications to traverse NATs. 

> So Suresh, you and everyone else as participants in the IETF is 
> responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG 
> item. 

[suresh] Magnus - I dont know what you are talking about. How do you mean I am
responsible for why the HOLE PUNCHING TECHNIQUE draft is not a WG item. The
ford-behave-app draft has been around for many years since the inception of
BEHAVE. Last I checked, The application milestone is no longer on BEHVAE
charter. I certainly am not responsible for removign the milestone.

>       The IETF has run its consensus process and it is now close to 
> completing and producing a ready specification. It may or may not have 
> been looking different if you had provided the details about how such a 
> solution would look. And worked to get consensus that it was what the 
> IETF wanted.
> 
> Complaining about the general design and tradeoffs after two WG last 
> calls and more than four years of development isn't productive. You all 
> contributed to the consensus process that has leads to this state. At 
> this point only serious bugs in the solution should be forcing any 
> backtracking. Revisiting our choices at this point is wasting time 
> unless there are very strong evidence that the choices made was wrong.
> 

[suresh] Magnus - I have not been part of the consensus for ICE. However, I do
know ICE adapts the HOLE PUNCHING TECHNIQUES and the BCP recommendations
identified in ford-behave-app draft. Yet, neither of the ICE drafts (UDP or the
TCP version) refer the ford-behave-app draft or prior work on HOLE PUNCHING as
normative reference. This iS WRONG. 

I believe, the ICE drafts should refer the prior work (kegel work on UDP hole
punching, USENIX paper for TCP hole punching and ford-behave-app draft for
application traversal design) on which the ICE work is based.

On the one hand, IETF (IESG) has been adamant about the standard level of the
normative references for a proposes standard. Yet, it is ironic that when HOLE
PUNCHING  is normative to the design of ICE, the IETF is not allowing the HOLE
PUNCHING work to be standardized. 

Why is the IETF not allowing HOLE PUNCHING TECHNIQUES and P2P application
traversal identified in draft-ford-behave-app draft to move forward as a BCP WG
item?

regards,
suresh

> I do understand that Henry is arguing for that more experience should be 
> gathered. But, I am not personally agreeing that we need more to publish 
> this as an proposed standard. There has been implementations, there have 
> been tests, there is even deployement as I understand it for earlier 
> versions. I think this all indicate that the general principle does 
> work. And it is great that we are seeing implementations being updated 
> to follow the latest spec, that will help confirm that things do work. 
> But, to me the ICE specification is the most reviewed, worked on 
> specification that I personally has been involved in within the IETF. We 
> are approaching fast the point where more baking will not make any 
> improvements worth wathing for. If there are some minor error are found 
> down the road, we can update the RFC at that point. But I don't see that 
> adding more delay or make it jump through more hops will be beneficial 
> at all. It only increases the time to complete a specification I think 
> the market really want.
> 
> 
> Cheers
> 
> Magnus Westerlund
> (Within his individual hat because this is not my WG)
> 
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jul 2007 15:24:35 +0200

Suresh,

I would propose that you drop MMUSIC mailing listif responding to this 
as you appear to want to discuss the removal of a BEHAVE milestone, 
rather than ICE and its way forward. But I will leave it there to let 
the MMUSIC people see my response.

It seems most of the issues in this discussion is between, what I at 
least thought was a specific way of performing the hole punching rather 
than the general concept that I acknowledge has existed since the 
creation of NATs. I will drop these items an respond to few of them.

> context of SIP and NAT traversal. So, I cant comment on this.

Yes, that was in the context of ICE. As my email was about that.

> charter. I certainly am not responsible for removign the milestone.

This was written as reaction on how work gets done in the IETF. One or 
more proponents goes out and sell their idea so that enough people are 
interested to participate in the work on that idea. In cases the 
proponents are not succesful in getting traction for the idea it rarely 
goes anywhere. In the case of the ford-behave-app draft there has been 
no support for keeping the milestone or more important, do the work.

> application traversal design) on which the ICE work is based.

I think you should review your sources here. The first version of 
ford-beahve-app was submitted february 2005. At that point STUN (RFC 
3489 had been published in almost 2 years (March 2003). The first 
individual version of ICE was submitted to IETF february 2003. I am not 
going to untangle this, but if you are going down this path: Please have 
you facts right.

I am not denying that work commonly builds up on others. And that it is 
common curtesy to reference such work. However, that is commonly done by 
an informative reference. Normative references are for things that you 
absolutely need to include to build interoperable implementations. 
Please do review IESG statement on references:

http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt

> PUNCHING work to be standardized. 

Once more a missunderstanding about what it means to be a normative 
reference in an RFC.

> traversal identified in draft-ford-behave-app draft to move forward as a BCP WG

As stated before. There is a clear lack of interest in this document. I 
wished there wasn't. But the fact is that no-one except you have really 
argued for it, not even your co-authors. We can't publish a document 
where no-one reads and reviews it and stil claim that their exist 
consensus behind it.

Regards

Magnus Westerlund