<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott, Keith L. wrote:<br>
<br>
<span style="white-space: pre;">> It seems to me that the points of
contention here center on whether<br>
> or not an application using UDP might cause network congestion and<br>
> hence lose packets, and whether/how building reliability on top of<br>
> UDP is a Good Idea. The arguments seem to oscillate between<br>
> high-bandwidth downlinks where we want to use all of the available<br>
> capacity and the assertion that UDP flows from space (there's a<br>
> B-movie title in there somewhere...) simply can't congest the<br>
> "network" because the space link bandwidth is too low.<br>
> <br>
> I would assert that for some (possibly many?) future missions, <br>
> bandwidths will be such that pure rate-controlled streams coming
from<br>
> some space applications would have the ability to congest shared<br>
> (space and/or ground). A single HDTV stream competing with any
other<br>
> appreciable flows in the ground or space portions of the network<br>
> could do this, e.g. I also don't think we can assert that streams<br>
> will not cross some portion of shared network, especially if there
is<br>
> inter-agency cross-support. One must consider the possibility of <br>
> commercial ground stations, and also the possibility of shared<br>
> in-space crosslinks.<br>
> <br>
> That said, do we all agree (at least among ourselves -- the case
will<br>
> need to be made to external audiences) that: 1) Moving to IP<br>
> provides a large benefit to missions in that: o it decouples<br>
> applications from the data links o it facilitates multi-hop routing<br>
> over heterogeneous data links o it provides an efficient
multiplexing<br>
> mechanism for numerous data types o traffic can be directly routed<br>
> from ground stations over closed networks or the Internet to its<br>
> destination(s) on the ground with commercial network equipment<br>
</span><br>
Yes.<br>
<span style="white-space: pre;"><br>
> 2) We don't really know how operators will want to use a networked<br>
> capability, except that they will probably want some mix of
real-time<br>
> data that can take loss and reliable data that wants no loss. These<br>
> are supportable in continuously connected environments by TCP, UDP,<br>
> and NORM (the latter two supporting simplex environments, to some<br>
> extent); and in disconnected environments by overlays like CFDP,
and<br>
> DTN.<br>
</span><br>
Yes. (And, as necessary, CFDP and DTN can be used in continuously
connected environments as well.)<br>
<span style="white-space: pre;"><br>
> 3) Building application-specific reliability mechanisms on top of
UDP<br>
> is an option, but *in general*, new applications should first look
to<br>
> standard transport mechanisms (exact list TBD from Red Books from<br>
> this WG) to fulfill their needs. Non-congestion controlled flows<br>
> that might cause significant network congestion are discouraged,
but<br>
> not prohibited if circumstances require their use and they can be<br>
> designed to 'not-too- adversely' affect the network. Note that<br>
> 'not-too-adversely' here is an overall system design trade -- a<br>
> particular application might need to simply blast bits without
regard<br>
> to the rest of the network. Note also that the overlays mentioned<br>
> above may be part of the recommended set of standard transports.<br>
</span><br>
That sounds right to me.<br>
<span style="white-space: pre;"><br>
</span>Scott<br>
</body>
</html>