Subject: RE: [dtn-interest] congestion in IPN
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Date: Mon, 30 Dec 2002 06:31:50 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

In #2, the phrase "One way to check congestion..." should be read as "One
way to check if there is a congestion ..."

Durga

Original Message:
-----------------
From: [email-masked] [email-masked]
Date: Mon, 30 Dec 2002 04:27:35 -0500
To: [email-masked]
Subject: [dtn-interest] congestion in IPN

1. Quoting from section 8.3 of the latest DTN Architecture Internet Draft: 

'One view of congestion control is as follows: "Congestion control is
concerned with allocating the resources in a network such that the network
can operate at an acceptable performance level when the demand exceeds or
is near the capacity of the network resources. These resources include
bandwidths of links, buffer space (memory), and processing capacity at
intermediate nodes. Congestion occurs when the demand is greater than the
available resources." [RJ90]'

My understanding of resource constraints in the IPN is that Bandwidth is
the most precious/valuable resource, followed by processing capacity and
buffer space respectively.  Am I right? What would it translate to
quantitively?

2. One way to check congestion on the terrestrial Internet is by
calculating the average queue length. This parameter may not be applicable
to IPN since it has been designed as a store and forward network, that
actually *expects* to have a large(how large?) queue. 
 
3. It has been shown by John Nagle (in RFC 970) that even in the
hypothetical case of a datagram network with infinite storage, congestion
will occur under overload. When packets arrive at a node at a rate higher
than they leave, a queue will build up delaying each successive packet with
the results that all packets will time out and be dropped. By analogy, even
if we have a large buffer space in the IPN, packets will drop out on
overload. How soon they drop depends on their lifetimes. From the DTN
draft, packets (bundles) are designed to have large lifetimes. 

*How large* do we actually expect the lifetimes to be? Has any work been
done on this? 

Regards
Durga

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Date: Mon, 30 Dec 2002 04:27:35 -0500
Subject: [dtn-interest] congestion in IPN
Sender: [email-masked]

1. Quoting from section 8.3 of the latest DTN Architecture Internet Draft: 

'One view of congestion control is as follows: "Congestion control is
concerned with allocating the resources in a network such that the network
can operate at an acceptable performance level when the demand exceeds or
is near the capacity of the network resources. These resources include
bandwidths of links, buffer space (memory), and processing capacity at
intermediate nodes. Congestion occurs when the demand is greater than the
available resources." [RJ90]'

My understanding of resource constraints in the IPN is that Bandwidth is
the most precious/valuable resource, followed by processing capacity and
buffer space respectively.  Am I right? What would it translate to
quantitively?

2. One way to check congestion on the terrestrial Internet is by
calculating the average queue length. This parameter may not be applicable
to IPN since it has been designed as a store and forward network, that
actually *expects* to have a large(how large?) queue. 
 
3. It has been shown by John Nagle (in RFC 970) that even in the
hypothetical case of a datagram network with infinite storage, congestion
will occur under overload. When packets arrive at a node at a rate higher
than they leave, a queue will build up delaying each successive packet with
the results that all packets will time out and be dropped. By analogy, even
if we have a large buffer space in the IPN, packets will drop out on
overload. How soon they drop depends on their lifetimes. From the DTN
draft, packets (bundles) are designed to have large lifetimes. 

*How large* do we actually expect the lifetimes to be? Has any work been
done on this? 

Regards
Durga

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Date: Thu, 19 Dec 2002 11:00:18 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Fwd: Re: IPN
Sender: [email-masked]

At 08:20 AM 12/19/2002 -0500, vinton g. cerf wrote:
>is there interest in another paper so soon?
>since one was just written by scott for ieee perhaps we should sit this 
>conference out?
>unless we have something new to say?

That sounds right to me.  We may have reached some new conclusions by July, 
but the April deadline for papers isn't that far away.

> >Date: Thu, 19 Dec 2002 09:19:26 +0000
> >From: "[email-masked]" <[email-masked]>
> >Subject: Re: IPN
> >To: vint cerf <[email-masked]>
> >X-Mailer: Pegasus Mail for Windows (v4.01)
> >Priority: normal
> >
> >Vint
> >
> >I am on the TPC for IFIP/IEEE MMNS:
> >
> >http://www.ee.qub.ac.uk/dsp/mmns2003/index.htm
> >
> >I was talking with some of the guys and mentioned that it would be
> >interesting to solicit a few papers on QoS issues associated with long-
> >distance protocols.
> >
> >I would be willing to contriibute to such a paper also.
> >
> >What do you think?
> >
> >Gerard
> >
> >=====================================================
> >=
> >Prof. Gerard Parr
> >Session/Track Chair Architectures/Protocols
> >IEEE MILCOM 2002
> >
> >
> >Internet Technologies Research Group
> >School of Information and Software Engineering
> >University of Ulster Coleraine Campus
> >Northern Ireland BT52 1SA
> >
> >Direct:    +44 (0) 28 70 324131
> >Secretary: +44 (0) 28 70 324440
> >Fax:       +44 (0) 28 70 324916
> >Mobile:    +44 (0) 79 67 381394
> >ISDN2:     +44 (0) 28 70 329283 (Intel ProShare)
> >
> >URL: http://www.infc.ulst.ac.uk/staff/gp.parr
> >
> >Check out our Advanced MSc Course in Telecommunications &
> >Distributed Systems
> >http://www.border.ulst.ac.uk/msc/index.html
> >
> >and also our Campus Spin-off Company- Causeway Data Communications
> >Ltd
> >http://www.cdc-ni.com
> >=====================================================
> >=
>
>Vint Cerf
>SVP Architecture & Technology
>WorldCom
>22001 Loudoun County Parkway, F2-4115
>Ashburn, VA 20147
>703 886 1690 (v806 1690)
>703 886 0047 fax
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 19 Dec 2002 08:20:43 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: Re: IPN
Sender: [email-masked]

is there interest in another paper so soon? 
since one was just written by scott for ieee perhaps we should sit this conference out?
unless we have something new to say?

vint

>Date: Thu, 19 Dec 2002 09:19:26 +0000
>From: "[email-masked]" <[email-masked]>
>Subject: Re: IPN
>To: vint cerf <[email-masked]>
>X-Mailer: Pegasus Mail for Windows (v4.01)
>Priority: normal
>
>Vint
>
>I am on the TPC for IFIP/IEEE MMNS:
>
>http://www.ee.qub.ac.uk/dsp/mmns2003/index.htm
>
>I was talking with some of the guys and mentioned that it would be 
>interesting to solicit a few papers on QoS issues associated with long-
>distance protocols.
>
>I would be willing to contriibute to such a paper also.
>
>What do you think?
>
>Gerard
>
>=====================================================
>=
>Prof. Gerard Parr
>Session/Track Chair Architectures/Protocols
>IEEE MILCOM 2002
>
>
>Internet Technologies Research Group
>School of Information and Software Engineering
>University of Ulster Coleraine Campus            
>Northern Ireland BT52 1SA 
>
>Direct:    +44 (0) 28 70 324131
>Secretary: +44 (0) 28 70 324440
>Fax:       +44 (0) 28 70 324916
>Mobile:    +44 (0) 79 67 381394
>ISDN2:     +44 (0) 28 70 329283 (Intel ProShare)
>
>URL: http://www.infc.ulst.ac.uk/staff/gp.parr
>
>Check out our Advanced MSc Course in Telecommunications & 
>Distributed Systems
>http://www.border.ulst.ac.uk/msc/index.html
>
>and also our Campus Spin-off Company- Causeway Data Communications 
>Ltd
>http://www.cdc-ni.com                             
>=====================================================
>=

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

Date: Sat, 07 Dec 2002 13:24:23 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] amazing relic
Sender: [email-masked]

--Boundary_(ID_LL7gnJwifN+3b/vkZhy9YA)
Content-type: text/plain; charset=us-ascii

http://www.jpl.nasa.gov/galileo/finger.html

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

--Boundary_(ID_LL7gnJwifN+3b/vkZhy9YA)
Content-type: text/html; charset=us-ascii

<html>
<font color="#0000FF"><u><a href="http://www.jpl.nasa.gov/galileo/finger.html" eudora="autourl">http://www.jpl.nasa.gov/galileo/finger.html<br><br>
</a></u></font><x-sigsep><p></x-sigsep>
Vint Cerf<br>
SVP Architecture &amp; Technology<br>
WorldCom<br>
22001 Loudoun County Parkway, F2-4115<br>
Ashburn, VA 20147<br>
703 886 1690 (v806 1690)<br>
703 886 0047 fax<br>
</html>

--Boundary_(ID_LL7gnJwifN+3b/vkZhy9YA)--

Date: Tue, 03 Dec 2002 19:27:46 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: Re: WWW comments (Forms submission)
Sender: [email-masked]

--Boundary_(ID_6Z8EJ2i/REvouAtG0q0RwQ)
Content-type: text/plain; charset=us-ascii

i thought these papers would be of general interest.

vint

>Date: Tue, 03 Dec 2002 16:58:05 -0500
>From: "Ian F. Akyildiz" <[email-masked]>
>Subject: Re: WWW comments (Forms submission)
>To: "vinton g. cerf" <[email-masked]>
>Reply-to: [email-masked]
>Organization: Georgia Tech
>X-Accept-Language: en-us, en
>User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920
> Netscape/7.0
>X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
>
>Dear Vint
>
>We just finished our work on
>
>TCP PLANET.
>
>Please find it in the attachment.
>
>Also we had a letter published IEEE Com Letters in Nov. 2002 issue
>where we point out the shortcomings of all existing TCP protocols
>in Deep Space Networks.
>
>Your feedback will greatly be appreciated.
>
>Best regards
>
>
>Ian
>
>
>
>vinton g. cerf wrote:
>>thanks!
>>At 09:09 AM 10/8/2002 -0400, Ian F. Akyildiz wrote:
>>
>>>Vint.
>>>
>>>
>>>>I'd be interestd in the proposals but even more interested
>>>>in the documentation of the protocols you have designed as
>>>>well as information about the prototypes. Are you planning
>>>>to release reference software?
>>>
>>>Yes.. We can release the software as well as all the
>>>papers/documents with our protocols.
>>
>>a pointer would be appreciated or email attachments.
>>
>>
>>>>Do you know about the SCPS version of TCP developed by
>>>>JPL for near-space applications?
>>>
>>>Yes, in fact we asked them to send their software
>>>last Friday and they did.
>>>
>>>We already have TCP Peach and extended version TCP Peach+
>>>for the same applications.
>>>These  were published in IEEE ToN and in IEEE Com Letters.
>>>If you do not have them I can send you copies.
>>>
>>>Also we have another short letter (to appear in IEEE Com
>>>Letters in Nov) where we show
>>>all existing TCP protocols fail miserably in deep space
>>>applications. I can also send it to you too.
>>
>>\yes please
>>
>>
>>>>What does RCS-Planet mean/do?
>>>
>>>RCS --> Rate Control Scheme for Real-Time applications.
>>>We have the prelim design for RCS
>>>(as described in the proposal)
>>>but our entire effort was to develop
>>>the TCP Planet the last 10 months.
>>>Once we are done with it we will move on to RCS Planet
>>>development.
>>>
>>>As I said I can keep you informed about our
>>>developments and keep you always in the loop.
>>
>>thanks
>>vint
>>
>>
>>
>>>Regards
>>>
>>>Ian
>>>
>>>
>>>
>>>>Vint
>>>>
>>>>At 08:44 AM 10/8/2002 -0400, Ian F. Akyildiz wrote:
>>>>
>>>>>Hi Vint
>>>>>
>>>>>Good to hear from you.
>>>>>
>>>>>The story is as follows:
>>>>>
>>>>>I was supported by NASA AMES, NASA GRC, DoD and NSF
>>>>>the last 5 years to conduct research on
>>>>>satellite networking (LEO/MEO/GEOs)
>>>>>(transport layer; routing, multicasting and error control).
>>>>>We produced many useful results.
>>>>>
>>>>>Based on these projects and experience
>>>>>I started this new project, DEEP SPACE NETWORKS last Fall.
>>>>>I had prepared two proposals:
>>>>>
>>>>>* Transport Layer Protocols: TCP-Planet and RCS-Planet
>>>>>
>>>>>* Routing in Deep Space Networks
>>>>>
>>>>>I was planning to send both proposals to NASA GRC.
>>>>>Unfortunately I missed the JUNE 24 deadline due to some stupid
>>>>>oversight.
>>>>>
>>>>>My team members continued the work on TCP PLANET.
>>>>>We developed the entire protocol. Very interesting solution
>>>>>in my opinion. We are in the phase of running simulations.
>>>>>
>>>>>I will be at Univ. of Maryland to present the first version of TCP
>>>>>Planet on Oct 25.
>>>>>
>>>>>
>>>>>I can keep you informed about our developments.
>>>>>
>>>>>I can send you the two proposals if you want.
>>>>>
>>>>>The bottomline is that I do not have funding
>>>>>for this particular project at this time
>>>>>but I am hoping to obtain funding and
>>>>>get into it very deeply. I am enjoying it.
>>>>>
>>>>>I look forward to hearing from you and indeed
>>>>>I am glad that we got in touch.
>>>>>
>>>>>Hope all is well with you.
>>>>>
>>>>>Best regards,
>>>>>
>>>>>Ian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>[email-masked] (vint cerf) sent the following comment:
>>>>>>
>>>>>>------------------------------------------------------------
>>>>>>ian,
>>>>>>
>>>>>>do you have funding for your deep space network
>>>>>>research and if so, from whom? how far have you
>>>>>>gotten in the work? see www.ipnsig.org for work
>>>>>>that has a 4 year history at JPL, along with
>>>>>>prototype protocols for the high level (above
>>>>>>transport). We have long base line link level
>>>>>>stuff done, but routing (which has to be
>>>>>>predictive based on celestial mechanics and
>>>>>>emphemerides as well as schedule) are still
>>>>>>sketchy.
>>>>>>
>>>>>>Vint
>>>>>>
>>>>>>------------------------------------------------------------
>>>>>> Server protocol: HTTP/1.1
>>>>>>     Remote host:
>>>>>>Remote IP address: 166.60.14.55
>>>>>> Client Software: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
>>>>Vint Cerf
>>>>SVP Architecture & Technology
>>>>WorldCom
>>>>22001 Loudoun County Parkway, F2-4115
>>>>Ashburn, VA 20147
>>>>703 886 1690 (v806 1690)
>>>>703 886 0047 fax
>>Vint Cerf
>>SVP Architecture & Technology
>>WorldCom
>>22001 Loudoun County Parkway, F2-4115
>>Ashburn, VA 20147
>>703 886 1690 (v806 1690)
>>703 886 0047 fax
>
>
>-- 
>Dr. Ian F. Akyildiz
>Ken Byers Distinguished Chair Professor in Telecommunications
>Broadband and Wireless Networking Laboratory
>School of Electrical and Computer Engineering
>Georgia Institute of Technology
>Atlanta, GA 30332
>
>Tel.: 404-894-5141
>Fax.: 404-894-7883
>E_mail: [email-masked]
>http://www.ee.gatech.edu/research/labs/bwn
>
>
>

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

--Boundary_(ID_6Z8EJ2i/REvouAtG0q0RwQ)
Content-type: application/pdf; name=TCP-Planet.pdf
Content-transfer-encoding: base64
Content-disposition: attachment; filename=TCP-Planet.pdf

--Boundary_(ID_6Z8EJ2i/REvouAtG0q0RwQ)
Content-type: application/pdf; name=deepspace.pdf
Content-transfer-encoding: base64
Content-disposition: attachment; filename=deepspace.pdf

--Boundary_(ID_6Z8EJ2i/REvouAtG0q0RwQ)--