Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Thu, 3 Jul 2003 19:51:25 -0500

>As has been said many times before, not all networks have the
>advantage of optical bandwidth.  Some ships must make do with 
>limited radio links. There are places in the world without 
>fiber.  Some users require high probability of connection even 
>when the emergency happens in a place with limited bandwidth.

I understand your point. This is not just common to limited cases
you depict. There are many places around deep space where you have 
constrained bandwidth and so, capacity management is a major issue. 
For example, a military sensor deployment or an ad-hoc network 
formation in a emergency spot depends on constrained BW in a 
multi-hop network.

I don't think ieprep WG can help you with this issue. I possibly
consider tranport level solutions in such scenarios as a non-starter.
Probably, a lot can be done at MAC layer for efficient capacity
management in such a power/BW-constrained environment. But, there 
are situations in which an intermediate wireless node may need to 
communicate with the source about its limited bandwidth. So, it can 
sent some kind of triggered notifications to the source. Their are 
other issues like corruption Vs loss in such environments. some of
these issues are addressed by Trigtran and many research groups.
On a parallel side, a whole research group by name "delay tolerant 
networks" is suggesting architecture for such environments.

what do you expect from ieprep for such deep space networks? 

>Steve Silverman
>
>> -----Original Message-----
>> From:
>> [mailto:[email-masked]]On Behalf Of
>> Ayyasamy, Senthilkumar (UMKC-Student)
>> Sent: Thursday, July 03, 2003 6:54 PM
>> To: King, Kimberly S.; Ieprep (E-mail)
>> Subject: RE: [Ieprep] IEPREP agenda Vienna meeting
>>
>>
>>
>>    >High Availability Networks               15 minutes
>>    >Discussion on high availability networks
>>
>> You mean high speed networks like Internet2 where BW*delay product
>> is high? or a backbone network? If we have high availability, why
>> should we worry about giving special priority to ieprep traffic?

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Steve Silverman" <[email-masked]>
Date: Fri, 4 Jul 2003 10:21:09 -0400

> From: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:[email-masked]]
> Sent: Thursday, July 03, 2003 8:51 PM
> To: Steve Silverman; King, Kimberly S.; Ieprep (E-mail)
> Subject: RE: [Ieprep] IEPREP agenda High Availability
> Networks Vienna
> meeting
>
>

Deep space has not been a case I have considered.  My primary focus
has been
voice which stops being very useful as the delay gets too great (I
would guess
 a 15 second delay would make voice sufficiently annoying that people
would turn to email.
But I don't know of any experimental research on what this limit is. )

> consider tranport level solutions in such scenarios as a

I didn't think IEPREP was constrained to Transport level solutions.
While
the WG is in the Transport Area, it is chartered to investigate the
requirements
in emergency comm.  As I understand it, the WG specifies requirements
that are to be passed
to other WGs to actually write protocols.  But these WGs don't have to
be in the Transport area.
If anyone disagrees with this (especially an AD) please correct me.

The solution I have been proposing for congested voice in a limited
bandwidth environment
is described in  < draft-silverman-diffserv-mlefphb-01.txt >.  (-02
will be submitted after the blackout.)
Unfortunately, the diffserv WG was closed
just before -00 was submitted so it is hard to  know where this should
be worked.  Note, the draft is
a proposed experimental RFC not a standards track.  This requirement
is for ceertain networks with special requirements
and probably for only some of the routers within that network (
routers on the bottlenecks).

Steve Silverman

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 04 Jul 2003 13:50:17 -0500

At 10:21 AM 7/4/2003 -0400, Steve Silverman wrote:

>I didn't think IEPREP was constrained to Transport level solutions. While 
>requirements in emergency comm.  As I understand it, the WG specifies 
>requirements that are to be passed to other WGs to actually write 
>protocols.  But these WGs don't have to be in the Transport area. If 
>anyone disagrees with this (especially an AD) please correct me.

OK, I do not agree, but that might only be in the way I read the above. You 
might have meant the clarification I have below that includes an important 
piece that was omitted from the above:

IEPREP is the type of WG that writes requirements for other WGs to 
*consider* doing protocol/mechanism work on. IEPREP cannot demand, nor does 
it direct WGs like SIP or MPLS to *do* work. It merely presents 
requirements that are not currently met by existing protocols "as is" and 
provides the justification (and not the solution) for how one or more 
protocols/mechanisms should be extended to satisfy those requirements.

Case in point is RFC 3487, which was produced by IEPREP for SIP(PING). That 
WG produced an ID very quickly (from our AD himself in fact) questioning 
some of the requirements the IEPREP WG reached consensus on. This action 
was following proper procedure within the IETF.

>bandwidth environment is described in  < 
>draft-silverman-diffserv-mlefphb-01.txt >.  (-02 will be submitted after 
>the blackout.) Unfortunately, the diffserv WG was closed just before -00 
>was submitted so it is hard to  know where this should be worked.  Note, 
>the draft is a proposed experimental RFC not a standards track.  This 
>requirement is for ceertain networks with special requirements and 
>probably for only some of the routers within that network (routers on the 
>bottlenecks).

In times of great disaster, whether natural or man-made, I find it somewhat 
curious that anyone can predict with certainty which routers will 
experience bottlenecks and which will not.... If there is any doubt in that 
prediction, any proactive mechanism proposal (such as this Diffserv ID) 
would need to be configured on all routers in a network, wouldn't it? I 
think the answer is yes.

>Steve Silverman

cheers,
James

                                *******************
                    The answer is "42", what's the question?