Discussion on SIP for Presence within the IETF.

Cullen Jennings | 7 Feb 2012 18:43

tsv-dir review of draft-ietf-simple-chat-13


I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF
documents. These comments were written primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address any issues raised. When done at the
time of IETF Last Call, the authors should consider this review together with any other last-call
comments they receive. Please always CC  tsv-dir <at> ietf.org if you reply to or forward this review.

Summary:

From a transport point of view, this draft is ready for publication as a PS RFC. 

From a transport and congestion point of view, this draft does not change any of the underling MSRP behavior
and thus this draft is the same as MSRP (RFC  4975 & RFC 4976). 

Details:

There is one issue in the draft related to transport that, if addressed, I think would improve the draft. 

Consider the case of  a chat room that is receiving messages at a rate of 10 per second (perhaps bad-attitude
during the IESG plenary) and also has some clients in the chat room that can only receiving messages at a
maximum rate of 5 per second ( perhaps an iphone via VPN over 2G). Section 6.1 does not say what should happen
in this case.

headers

Miguel A. Garcia | 8 Feb 2012 11:38

Re: tsv-dir review of draft-ietf-simple-chat-13

Hi Cullen,

Thanks for your review. See inline comments.

On 07/02/2012 18:43, Cullen Jennings wrote:

> Consider the case of  a chat room that is receiving messages at a rate
> of 10 per second (perhaps bad-attitude during the IESG plenary) and
> also has some clients in the chat room that can only receiving
> messages at a maximum rate of 5 per second ( perhaps an iphone via VPN
> over 2G). Section 6.1 does not say what should happen in this case.

I understand the problem description. The question is whether we want to 
make the application layer aware of potential congestion and take actions 
on it.

I don't know how the chat room application could in the first place 
detect congestion. Any ideas of what to write in the draft are highly 
appreciated.

/Miguel

--

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

headers

Cullen Jennings | 13 Feb 2012 21:30

Re: tsv-dir review of draft-ietf-simple-chat-13

On Feb 8, 2012, at 3:38 AM, Miguel A. Garcia wrote:

> Hi Cullen,
> 
> Thanks for your review. See inline comments.
> 
> On 07/02/2012 18:43, Cullen Jennings wrote:
> 
>> Consider the case of  a chat room that is receiving messages at a rate
>> of 10 per second (perhaps bad-attitude during the IESG plenary) and
>> also has some clients in the chat room that can only receiving
>> messages at a maximum rate of 5 per second ( perhaps an iphone via VPN
>> over 2G). Section 6.1 does not say what should happen in this case.
> 
> I understand the problem description. The question is whether we want to make the application layer aware
of potential congestion and take actions on it.
> 
> I don't know how the chat room application could in the first place detect congestion. Any ideas of what to
write in the draft are highly appreciated.

Note - I'd be OK with publishing the document with no change but I think some text would improve the draft.

I think the most important part is just point out that this is a problem and applications need to have a
strategy to deal with it. I would not prescribe a strategy that apps had to implement but instead have some
non normative strategies that an application might use. One strategy is that is any client falls more than
10 seconds behind, that client get disconnected.

headers

Miguel A. Garcia | 14 Feb 2012 07:51

Re: tsv-dir review of draft-ietf-simple-chat-13

Your proposal sounds reasonable. Thanks.

/Miguel

On 13/02/2012 21:30, Cullen Jennings wrote:
>
> On Feb 8, 2012, at 3:38 AM, Miguel A. Garcia wrote:
>
>> Hi Cullen,
>>
>> Thanks for your review. See inline comments.
>>
>> On 07/02/2012 18:43, Cullen Jennings wrote:
>>
>>> Consider the case of  a chat room that is receiving messages at a rate
>>> of 10 per second (perhaps bad-attitude during the IESG plenary) and
>>> also has some clients in the chat room that can only receiving
>>> messages at a maximum rate of 5 per second ( perhaps an iphone via VPN
>>> over 2G). Section 6.1 does not say what should happen in this case.
>>
>> I understand the problem description. The question is whether we want to make the application layer
aware of potential congestion and take actions on it.
>>
>> I don't know how the chat room application could in the first place detect congestion. Any ideas of what to
write in the draft are highly appreciated.
>
> Note - I'd be OK with publishing the document with no change but I think some text would improve the draft.
>
> I think the most important part is just point out that this is a problem and applications need to have a
strategy to deal with it. I would not prescribe a strategy that apps had to implement but instead have some

(Continue reading)