Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt

[Jiri Kuthan <jiri at iptel.org>]

Francois Audet wrote:
> Jiri,
> 
> I think we are in 100% agreement then.

great.

> 
> For UDP... I was certainly not a proponent of the STUN idea.
> But after 6 months of arguing on the list and about 6000 postings, 
> the group decided to use STUN.
> 
> I don't think we want to re-open that can of worms.

:-)

well perhaps having just a keep-alive app-indepednet document would be 
worth it, regardless what other combined work is going elsewhere :-) 
Anyhow, embedded STUN doesn't in fact appear so terrible to me.

So after all, what do we want to do for keeping bindings alive? a) BCP 
b) ignore c) sip-keep. (sorted in my strongly descending order of 
preference).

-jiri

> 
>> -----Original Message-----
>> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
>> Behalf Of Jiri Kuthan
>> Sent: Thursday, May 08, 2008 00:15
>> To: Audet, Francois (SC100:3055)
>> Cc: sip at ietf.org; Christer Holmberg
>> Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt
>>
>> Francois Audet wrote:
>>>  
>>>> Then we may very well consider making "respond to CRLF 
>> with CRLF" a 
>>>> proposed standardized way too.
>>>> I mean it is simple and works. Which I prefer over negotiation 
>>>> protocols.
>>> So, basically, you are proposing that for connection-oriented 
>>> transport, we use "respond to double-CRLF with single-CRLF" 
>> instead of Christer's draft.
>>> I assume that would mean that for UDP transport, we'd still 
>> be using 
>>> Christer's draft.
>>>
>>> Is this your proposal?
>> Hi Francois
>>
>> quite so, even I'm still a bit uncertain about what the least evil is
>> :-) I think it is suboptimal to negotiate transport 
>> characterictics using application-specific protocol. CRLF^2 
>> seems almost the right thing for TCP. TCP/keepalive seems 
>> even better to me -- I mean we can use it for every single 
>> app without reinventing the wheel. However I'm afraid that 
>> even if "cleaner", it would not work quite so well.
>>
>> The trouble with TCP/keepalive is twofold. One is, as Hadriel 
>> mentions, there are OSs that can't deal with it. The question 
>> is how serious shall be in protocol design about OSs whose 
>> TCP stack is not yet state-of-the-art. I'm inclined to be 
>> easy about it, this can be fixed. 
>> The other problem is very similar: there are NATs that ignore 
>> TCP keep-alives to extend bindings. The question is again how 
>> serious shall be in protocol design about software that could 
>> have been better. I'm actually worried more about the latter 
>> under the assumption that network is "imperfect" and 
>> end-devices better compensate for it. Thus I think
>> CRLF^2 is the most preferable way for its robustness.
>>
>> Regarding UDP -- is there anything speaking against CRLF^2 
>> too? I mean keeping things simple and non-special-cased is a 
>> good thing and I don't realized why this should not work.
>>
>> -jiri
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use 
>> sip-implementors at cs.columbia.edu for questions on current sip 
>> Use sipping at ietf.org for new developments on the application of sip
>>
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip