Subject: RE: [Simple] MSRP NAT traversal

From: <[email-masked]>
Date: Wed, 1 Aug 2007 10:59:44 +0300

Hisham, 

See inline with [Markus]:

________________________________

	From: ext Hisham Khartabil [mailto:[email-masked]] 
	Sent: 27 July, 2007 07:30
	To: Isomaki Markus (Nokia-SIR/Espoo)
	Cc: [email-masked]; [email-masked]
	Subject: Re: [Simple] MSRP NAT traversal

	I think we are always in the habbit on being 10 years ahead of
implementation and always trying to design an alternative solution to a
solution that has not been proven broken.

[Markus] Of course we should give our specs a fair chance before
creating alternatives but I think we must also pay attention to what
people who deploy these things want rather than expecting them always do
things in the way it was originally designed in the IETF. In the worst
case they will do things differently anyway, without a proper open spec,
and then the interop is even worse. The reason I sent my mail was to get
a feeling what people think the situation is with MSRP, MSRP relays,
TURN and SBCs. From my perspective I know for sure that there are
efforts going on outside IETF (between vendors etc.) to see how MSRP
could work through SBCs. On the other hand I've not heard of plans to
use relays. But certainly this is just a single view and I'd like to
understand how others implementing or deploying see it. It may be that
even if we wanted something, it is too complicated to add it as an
extension anymore.
	 
	We spent years on designing MSRP and MSRP relay. Now that they
are finally becoming RFCs, we want an alternative solution. One that
will cause interoperability problem in the sense that different
implementors will choose different solutions. This will cause further
work in order to negotiate the NAT traversal solution between endpoints.

	- Why is not using comedia a mistake?

[Markus] MSRP fixes the direction of who opens the TCP connection. In
comedia the endpoints can negotiate this. So, with comedia you can get
end-to-end TCP always if at least one of the endpoints can receive
incoming TCP connections. For instance an MSRP chat server would
typically be such an endpoint. 

	- Why is it valuable?
	- Why isnt MSRP Relay sufficient?

[Markus] It is sufficient but it is yet another box to put in your
network. Most networks already have SBCs and hopefully soon TURN relays
as well and these can handle TCP. So, logically they would like to use
them for MSRP and not require a specific solution just for that. In case
they would like to do something more than just NAT traversal, they could
probably use relay, but AFAIK that is a minority case. 
	 
	Config framework work is another example where people are
proposing something else before the config framework has been proven
broken.

[Markus] That has nothing to do with this discussion related to MSRP,
you should bring that up where it belongs.
	 
	I don't know why you would want to standardise something that is
not any better than an existing solution.

[Markus] I don't know either, but I tried to explain the benefits I can
see. If there are not enough people who agree with them, this is
obviously going nowhere (in the IETF). But there are some who do
already.
	 
	Hisham

Regards,
	Markus

	On 25/07/07, [email-masked] <[email-masked]
> wrote: 

		Hi,
		
		Now that MSRP has been finally approved as an RFC, it
would be nice to
		get some actual implementations and even deployments for
it. Based on 
		what I've heard there are several client implementations
under
		development (for instance to support file/image transfer
service). The
		problem is that I've got a sense that the interest to
support MSRP relay 
		extension seems to be quite low. I'm not sure if there
are MSRP relay
		implementations under development. Instead it seems that
many people
		would rather have MSRP NAT traversal using SBCs (based
on comedia) or 
		ICE/TURN.
		
		Personally I think that the decision in MSRP not to use
comedia has been
		a mistake. It's not possible to change that anymore in
the MSRP base
		spec, but I think it would be valuable to define how to
negotiate MSRP 
		with comedia in an extension spec. This would allow MSRP
to work in
		situations where one of the endpoints can receive
incoming TCP
		connections, as well as with SBCs supporting comedia.
		
		Also the work started in 
	
http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt
		should be brought to completion.
		
		I would be interested in hearing comments whether people
think that MSRP 
		relays are going to be sufficient for MSRP NAT traversal
(and especially
		if there are implementation plans) or if there is
interest in defining
		how MSRP works with comedia as an alternative mechanism.
My goal would 
		be to do whatever is best to have MSRP deployable.
		
		Regards,
		       Markus

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

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

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 2 Aug 2007 14:55:50 +1000

On 01/08/07, [email-masked] <[email-masked]> wrote:
> and then the interop is even worse.

The IETF has participants from service providers (people who deploy these
things) as well as vendors (people who build these things). You cannot claim
that IETF participants are different from those people.

 The reason I sent my mail was to get
> typically be such an endpoint.

That's a bogus limitation. What endpoints do you know that can receive TCP
connections but can't open them?

       - Why is it valuable?
> probably use relay, but AFAIK that is a minority case.

MSRP Relay can be implemented in SBCs. Its a logical entity, not a physical
box.

Hisham

---

From: <[email-masked]>
Date: Thu, 2 Aug 2007 11:13:26 +0300

Hisham, 
	 
	The IETF has participants from service providers (people who
deploy these things) as well as vendors (people who build these things).
You cannot claim that IETF participants are different from those people.

[Markus] True, but this does not mean that the initial specs always
solve all deployment related problems in an optimal or even sufficient
way. I've heard about protocols being extended and even obsolited for
these reasons.  	 

		[Markus] MSRP fixes the direction of who opens the TCP
connection. In
		comedia the endpoints can negotiate this. So, with
comedia you can get 
		end-to-end TCP always if at least one of the endpoints
can receive
		incoming TCP connections. For instance an MSRP chat
server would
		typically be such an endpoint.

	That's a bogus limitation. What endpoints do you know that can
receive TCP connections but can't open them?

[Markus] It's not bogus at all. The limitation is valid when the *other*
endpoint is behind a NAT (or firewall) and that's why you can't open the
connection. If you are not NATed yourself, opening the connection from
that other endpoint will work, however. In practice the difference is
that current MSRP will not work in the case where the SDP answerer is
NAT'ed while the offerer is not, but MSRP+comedia would work in that
case too (without relays). 
	 
		       - Why is it valuable?
		
		[Markus] It is sufficient but it is yet another box to
put in your 
		network. Most networks already have SBCs and hopefully
soon TURN relays
		as well and these can handle TCP. So, logically they
would like to use
		them for MSRP and not require a specific solution just
for that. In case 
		they would like to do something more than just NAT
traversal, they could
		probably use relay, but AFAIK that is a minority case.

	MSRP Relay can be implemented in SBCs. Its a logical entity, not
a physical box.
	 
[Markus] Great. Logical entities are so much easier to deploy than boxes
;)

	Hisham

Markus