Subject: RE: [Ietf-behave] Re: adding SCTP at behave milestone

From: "Francois Audet" <[email-masked]>
Date: Tue, 22 Feb 2005 09:40:23 -0800 (PST)

Isn't the solution to this really simple:
let people who are interested continue to work on it,
with the understanding that we will go to last call
on the other most important document first?

My 2 cents...

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Cullen Jennings
> Sent: Tuesday, February 22, 2005 09:38
> To: Randall Stewart
> Cc: Behave
> Subject: [Ietf-behave] Re: adding SCTP at behave milestone
> 
> 
> 
> > thought it would not be part of the "ocean" of protocols... 
> especially 
> > since there are only 3 at the transport level.. maybe 4 if 
> we include 
> > DCCP
> 
> Ok, Ok, I agree, it's hardly an ocean :-)  Perhaps a handful 
> of small streams would be a better analogy. The streams are 
> of course complete with log jams, waterfalls, water diversion 
> projects, industrial waste sites, and plans to make bypasses 
> for high-speed salmon.
> 
> > 
> > But.... as I said... I understand.. if thats not a priority thats 
> > fine.. we can pick up the work later.. but I think Q and I will 
> > continue to work on the draft and get it closer to 
> capturing all the 
> > issues (forgoing m-homing however)..
> > 
> 
> I'd never discourage anyone from pursing useful work. And 
> it's not that SCTP could never fit into behave, it could,  we 
> just need to finish some other stuff first. Glad to see 
> people thinking about the future but also anything you can do 
> to accelerate the other stuff is good too.
> 
> Cullen 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 22 Feb 2005 09:52:35 -0800 (PST)

On Tuesday, February 22, 2005, at 12:40 PM, Francois Audet wrote:
Isn't the solution to this really simple:
let people who are interested continue to work on it,
with the understanding that we will go to last call
on the other most important document first?
Anybody can work on anything, obviously.  Working group milestones
are another matter, and it makes sense to be a bit conservative
in agreeing to deliver deliverables.
Also, the specific question that was posed was whether or not to make
Qiaobing's draft a working group document.  I have nothing but respect
for Qiaobing's excellent work in a number of areas, but I think that
this one draft is really not very good.  I don't think the multihomed
traversal problem is framed very coherently and the proposed solution
(a nat/nat protocol) is just wrong, for reasons I've outlined 
previously.

Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 22 Feb 2005 09:57:25 -0800 (PST)

IMO, it may not be necessary that SCTP-NAT be added as a high priority milestone. But to 
have a WG draft that people can find on the WG web page would be very helpful.

regards,
-Qiaobing
Francois Audet wrote:

 > to accelerate the other stuff is good too.
------------------------------------------------------------------------

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 22 Feb 2005 10:31:27 -0800 (PST)

Melinda,

This is why I suggested that making it a WG item would help - more people can read it more 
carefully and contribute to its improvement.

As to the particular issue of nat/nat protocol, you may have mis-read the draft badly.

I know your view on this nat/nat protocol issue (and I dislike it too), but I have no idea 
where you got the impression that the draft is proposing a solution based on a nat/nat protocol.

Here is the only place that topic is mentioned in the draft:

"  This [state sync among NATs] can only be
   possible if there exists some inter-NAT protocol which can provide
   coordination amongst the NATs when the association is set up.
   Further study is needed for this scenario.
"
As to the multi-homed traversal problem, how do you want to frame it?

regards,
-Qiaobing
Melinda Shore wrote:

(a nat/nat protocol) is just wrong, for reasons I've outlined previously.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 22 Feb 2005 10:40:27 -0800 (PST)

On Tuesday, February 22, 2005, at 01:34 PM, Qiaobing Xie wrote:
"  This [state sync among NATs] can only be
   possible if there exists some inter-NAT protocol which can provide
   coordination amongst the NATs when the association is set up.
   Further study is needed for this scenario.
Yes - what I didn't like was the assumption that the NAT was the
place to "fix" the problem.
As to the multi-homed traversal problem, how do you want to frame it?
I'd like to see the problem decomposed into its component pieces
(the address use problem being distinct from the single port number
problem, for example).  There also needs to be more discussion of the
security implications - IPSec is going to be a real problem if the
NAT is going to be tinkering with chunk contents.
Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 23 Feb 2005 10:53:06 -0800 (PST)

Melinda Shore wrote:

"  This [state sync among NATs] can only be
   possible if there exists some inter-NAT protocol which can provide
   coordination amongst the NATs when the association is set up.
   Further study is needed for this scenario.
Yes - what I didn't like was the assumption that the NAT was the
place to "fix" the problem.
The quoted sentence is by no means a proposal. It merely says that if in the future such a 
thing becomes available (for whatever reasons), then SCTP may be able to make use of it. 
This sentence can be taken out without consequence.

I'd like to see the problem decomposed into its component pieces
(the address use problem being distinct from the single port number
problem, for example).  
A key concept must be understood when discussing SCTP and NAT issues. That is the 
single-point traversal vs. multi-point traversal (described in full detail in the draft). 
This is *not* the same as the singly-homed SCTP association vs. multi-homed association. I 
sense a lot of confusion between the two concepts in the present discussion.

For single-point NAT traversal, the SCTP association can be either singly-homed or 
multi-homed. In this case, it is very *straightforward* to make SCTP work with NAT. Anyone 
who understands how TCP/NAT works would be able to understand how SCTP/NAT will work in this 
scenario. The one vendor I mentioned earlier which has commercial products deployed in a 
telecom environment followed this approach.

However, the real problem is with the multi-point traversal case. Frankly, I don't know if 
there is a solution for that. I'd say, it probably should be a research topic.

How many people will be pretty happy to live with only single-point traversal? I'd say 
probably 99% will. For the few customers requiring extremely high availability to their 
networks (e.g., military or 5 Nine telecom), there are alternative ways to achieve that 5 
Nine, such as using a NAT built on a HA redundant platform.

> There also needs to be more discussion of the
security implications - IPSec is going to be a real problem if the
NAT is going to be tinkering with chunk contents.
Agreed. This is the same issue facing any ALGs.

regards,
-Qiaobing
Melinda