Subject: [MMUSIC] Connection and connectivity preconditions

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 04 Apr 2005 11:27:17 +0300

Folks,

in the last IETF we discussed how to proceed with the following both drafts:

draft-andreasen-mmusic-connectivityprecondition-02.txt
draft-ietf-mmusic-connection-precon-01.txt

The former defines connectivity (e.g., RTP No-Op or ICE-based) 
preconditions and the latter defines connection-oriented (e.g., TCP or 
SCTP-based) preconditions.

The question is what to do to handle scenarios using connection-oriented 
protocols. The choices are:

1) Merge both documents so that only one precondition type is defined 
which, for connection-oriented protocols, is met when the connection 
establishment procedure finishes (e.g., a successful TCP 3-way handshake).

2) Leave the second draft as it is and define in the first draft further 
conditions that should be met for connection-oriented protocols. For 
example, the connection establishment procedure needs to be successfull 
*and* you have to run some type of connectivity check on top of it to 
ensure that you are talking to the correct remote endpoint.

In principle, Flemming and I thought that option 1) was the way to go, 
but in the meeting some folks talked about option 2).

Given that, at present, nobody is implementing something like option 2) 
(if somebody is doing it please speak up), my proposal would be to go 
for option 1).

Comments?

Thanks,

Gonzalo

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

---

From: David R Oran <[email-masked]>
Date: Wed, 6 Apr 2005 17:36:49 -0400

Option 1 works for me as long as we are clear that 
"connection-oriented" means "with working transmission during the data 
phase". The semantics are the same in that case. For TCP pragmatically 
we can say that the data is likely to get through or the connection 
will get torn down. However, if we were to have a connection-oriented 
protocol that did *not* provide data-phase reliability (I get a small 
tingle that SCTP can actually be configured in this mode), one would 
want some confidence that data was actually getting through during the 
data phase and not just that some establishment handshake worked.

So, a few words to that effect would tighten things up and make it 
clear that the requirement to satisfy the precondition is having 
confidence that the goodput of the subject flow is sufficiently greater 
than zero to make the flow usable or you will get an explicit teardown. 
If you can do that with just the handshake (as in the case of TCP) then 
nothing more is needed.

Dave.

On Apr 4, 2005, at 4:27 AM, Gonzalo Camarillo wrote:

> The question is what to do to handle scenarios using 
> connection-oriented protocols. The choices are:
>
> 2) Leave the second draft as it is and define in the first draft 
> further conditions that should be met for connection-oriented 
> protocols. For example, the connection establishment procedure needs 
> to be successfull *and* you have to run some type of connectivity 
> check on top of it to ensure that you are talking to the correct 
> remote endpoint.
>
>
> Given that, at present, nobody is implementing something like option 
> 2) (if somebody is doing it please speak up), my proposal would be to 
> go for option 1).
>
> Comments?
>
> Thanks,
>
> Gonzalo
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]