[MMUSIC] Re: Connection and connectivity preconditions

[David R Oran <[e-mail]>]

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:

> 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
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: [phone]
Email: [e-mail]

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