Subject: [Atoca] Requirement D2: "Large Audience"

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 21:30:24 +0200

Hi all, 

during the ATOCA meeting at IETF#79 Igor raised a question regarding requirement D2:
"
   Req-D2:

      The protocol solution MUST allow delivery of messages
      simultaneously to a large audience.
"

He was asking whether there is a need to put a number for large audience there.

Maybe Igor has a specific number in mind that would matter from a protocol design perspective but I do not have such a number that would provide a meaningful distinction. 

There is, however, the question what types of problems we expect with very large number of alert message receivers and how we document this aspect in the requirements document. 

Suggestions? Thoughts? 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 16 Jan 2011 17:22:04 +0200

Hi Art, 

that's an interesting comment particularly since we do not have a requirement for responses by receivers (or Recipients) of alert messages. I am not sure to whom they would sent their response to. To the originator, to some gateway, etc? 

Ciao
Hannes

On Jan 15, 2011, at 11:58 PM, Art Botterell wrote:

> One difference in "broadcast" delivery is that it's frequntly impractical and/or undesirable to try to track individual deliveries or process individual responses.
> 
> Thanks!
> 
> - Art
> 
> On Jan 15, 2011, at 11:30 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
>> Hi all, 
>> 
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning

---

From: Art Botterell <[email-masked]>
Date: Sat, 15 Jan 2011 13:58:14 -0800

Thanks!

- Art

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 17 Jan 2011 07:15:04 +0800

On Jan 15, 2011, at 11:58 PM, Art Botterell wrote:
> One difference in "broadcast" delivery is that it's frequntly
> impractical and/or undesirable to try to track individual deliveries or
> process individual responses.

If SIP is our delivery mechanism, can anything be done to suppress 200 responses to NOTIFY requests?  Is there any point if we're using acknowledged transport like TCP?  Is there a concern that unacknowledged packets (UDP) will get dropped?

The potential to create congestion worries me.

--Martin

---

From: Art Botterell <[email-masked]>
Date: Sun, 16 Jan 2011 23:20:37 -0400

Mainly I was just suggesting one way of looking at the "how large is 'large'" question.  Although it does highlight some of Martin's questions about how to adapt a session initiation protocol to a one-to-very-many application, if that's what we have in mind.  As he rightly points out, responses don't only happen at the application level.

Thanks!

- Art

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 17 Jan 2011 13:12:05 +0800

Interesting tidbit from the Australian warning system discussions: the originating systems (the first relay) provides a report to the emergency authority on the number of deliveries.  That suggests that feedback occurs at some level.

I don't know whether this sort of reporting is something that would be part of a requirement, but I'll try to find out.

--Martin

On 2011-01-17 at 14:20:37, Art Botterell wrote:
> Mainly I was just suggesting one way of looking at the "how large is
> 'large'" question.  Although it does highlight some of Martin's
> questions about how to adapt a session initiation protocol to a one-to-
> very-many application, if that's what we have in mind.  As he rightly
> points out, responses don't only happen at the application level.
> 
> Thanks!
> 
> - Art
> 
> > that's an interesting comment particularly since we do not have a
> requirement for responses by receivers (or Recipients) of alert
> messages. I am not sure to whom they would sent their response to. To
> the originator, to some gateway, etc?
> >
> > Ciao
> > Hannes
> >
> >>> Maybe Igor has a specific number in mind that would matter from a
> protocol design perspective but I do not have such a number that would
> provide a meaningful distinction.
> >>>
> >>> There is, however, the question what types of problems we expect
> with very large number of alert message receivers and how we document
> this aspect in the requirements document.
> >>>
> >>> Suggestions? Thoughts?
> >>>
> >>> Ciao
> >>> Hannes
> >>>

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 17 Jan 2011 20:09:05 -0500

With many thanks to Hannes for a thorough follow-up on my humble 
questions, I just wanted to clarify that my question about "large 
audience" arose only because I was trained to test, and the word "large" 
is not something that any test can verify. Since the requirements has a 
MUST in it, it ought to be verifiable. (And I remember Scott echoed this 
by pointing to the word "simultaneously" as potentially problematic, too.

To this end, I am happy with the proposal to  use the term "broadcast."  
How about re-writing Req-D2 as follows:  

>
>       The protocol solution MUST allow broadcast delivery of messages
>        to the targeted audience.
>
>   
In this case, we avoid specification of the size of the audience as well 
as the issues of verifying simultaneity (broadcast takes care of  it).

On the issue of authentication/authorization, I actually meant exactly 
what Brian had said a while ago: The broadcaster has to be authenticated 
(lest a rogue entity creates panic or disrupts the network or both), and 
the network will deal with the authorization.  Indeed, TLS with client 
authentication (preferably, PKI-based) is a solution that I think perfect.

Igor

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 18 Jan 2011 13:52:42 +0100

Surely if you supress the responses then it is no longer SIP, but some other entirely new protocol.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomson, Martin
> Sent: Sunday, January 16, 2011 11:15 PM
> To: Hannes Tschofenig; Art Botterell
> Cc: Faynberg, Igor (Igor); [email-masked]
> Subject: Re: [Atoca] Requirement D2: "Large Audience"
> 
> > impractical and/or undesirable to try to track individual 
> deliveries 
> > or process individual responses.
> 
> If SIP is our delivery mechanism, can anything be done to 
> suppress 200 responses to NOTIFY requests?  Is there any 
> point if we're using acknowledged transport like TCP?  Is 
> there a concern that unacknowledged packets (UDP) will get dropped?
>