Re: [Ieprep] on the ieprep charter

Rex Buddenberg <budden@nps.navy.mil> Fri, 28 July 2006 16:16 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6V18-0002ex-K1; Fri, 28 Jul 2006 12:16:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6V17-0002es-Dv for ieprep@ietf.org; Fri, 28 Jul 2006 12:16:49 -0400
Received: from virginia.nps.edu ([205.155.65.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6V15-0004CC-JP for ieprep@ietf.org; Fri, 28 Jul 2006 12:16:49 -0400
Received: from north-latitude.nps.navy.mil ([131.120.179.249] RDNS failed) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:17:34 -0700
Subject: Re: [Ieprep] on the ieprep charter
From: Rex Buddenberg <budden@nps.navy.mil>
To: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk>
References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <B8C892A4-F711-4928-8EDA-FD7E717B702F@cisco.com> <44C9160F.1060001@jhuapl.edu> <DBC1A7C7-9F3C-4557-A7BC-E081C482A5C3@cisco.com> <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk>
Content-Type: text/plain
Date: Fri, 28 Jul 2006 09:16:39 -0700
Message-Id: <1154103399.5427.366.camel@north-latitude.nps.navy.mil>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.0
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jul 2006 16:17:34.0178 (UTC) FILETIME=[55728C20:01C6B261]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: "Robert G. Cole" <robert.cole@jhuapl.edu>, Fred Baker <fred@cisco.com>, ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

Ken,

You're correct on multicast.  Reinforce:

- demand side.  A great deal of data in both military and emergency
services is multicast in nature.  Much higher proportion than in
commercial world.  And as soon as you factor in high availability
engineering, everything becomes multicast -- you send data >1 place so a
lucky hit on target A doesn't take all the data.  

- supply side.  Increasingly we can look at the radio-WANs as interior
network segments.  Platforms have LANs in them and the radio-WAN has no
end systems on it -- they're all on the LAN, other side of the router.
This is most obvious in the surface navy today, but it's a trend.  Both
LANs and the fixed internet are or can easily be provisioned at G and
10G capacities (even in US DoD!).  But as soon as you hit the radio-WAN
in the middle, you suffer ~4 order of magnitude capacity hit -- best
numbers are in 10s of M.  Multicast is the only offset to that capacity
hit.

PTT radios are just one instantiation of this observation.


On Thu, 2006-07-27 at 23:27 -0400, ken carlberg wrote:
> > What the charter should, perhaps, address, is the status of  
> > multicast in this. We all agree we need unicast solutions. RSVP  
> > assumes that multicast is also a requirement, while NSIS presumes  
> > that it can be summarily set aside. In civilian networks where  
> > multicast is not widely deployed as a service, the point may be  
> > moot. I am told that in your organization and others in coalition  
> > with it, there are places where multicast is the predominant  
> > traffic type, however. So we have to decide whether we need to  
> > address that.
> 
> I'll chime up and say we *definitely* need to address multicast.  its  
> fundamental in the context of efficiently supporting push-to-talk  
> applications as one pushes IP further into the infrastructure of Land  
> Mobile Radio.  and the subject becomes more of a headache since the  
> establishment of talk groups are not based on explicitly signaled CAC
> 
> -ken
> 
> 
> _______________________________________________
> Ieprep mailing list
> Ieprep@ietf.org
> https://www1.ietf.org/mailman/listinfo/ieprep
-- 
b



_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep