[Sis-csi] Telecon scheduling and request for requirements

[Scott, Keith L.]

========== Telecon scheduling

I apologize for this but we're going to need to reschedule our weekly
telecons, starting with today's.  Hopefully this will be the last time
we'll have to do this for a while.  I'll start off by proposing one
hour earlier on Thursdays (11:30 pacific, 1:30 central, 2:30 eastern).
Please let me know if this works for you and, if not, what would.  If
we can't come to consensus quickly we'll wave off this week's telecon,
but please see below on a request for requirements from the High Rate
Uplink WG in SLS; I'd like to hash this out over email and get them an
answer by next week.

========== Request for Requirements from High-Rate Uplink WG

Following up from the Colorado Springs meetings, we've received a
request for requirements from the High Rate Uplink WG (CWE at
http://public.ccsds.org/sites/cwe/sls-hru/default.aspx?RootFolder=%2fsi
tes%2fcwe%2fsls%2dhru%2fPublic%2fCharters&View=%7bED7A93D1%2d1BB1%2d403
3%2d8432%2dD7382F71947D%7d).  In particular they want to know what
kinds of uplink rates the cislunar architecture would require.  I think
that our DOWNLINK requirements should at least cover current shuttle
and station rates of ~150Mbps, but I don't think we require full
symmetry on the uplink.

The largest driver for the uplink rate might be crew accommodation of
live HDTV events, which would be on the order of 5-10Mbps, if they were
actually provided.  If we had that then we should be able to cover most
or all of the operational uplink traffic in the margin!  :)  Just as
another point of reference, 150Mbps of TCP downlink would require
~2Mbps of TCP ACK traffic.  We also need to remember that in a
networked world such as we've proposed, one uplink may be serving
several spacecraft.

In any case, we need to provide them with a number that:
	1) Is large enough to cover our requirements for a reasonable
amount of time
	2) Is not so large that they roll on the floor laughing at us

Regardless of the rate requirement, RFC3819 (Advice for Internet
Subnetwork Designers) and maybe rfcs RFC3155 (End-to-end Performance
Implications of Links with Errors) and RFC3366 (Advice to link
designers on link Automatic Repeat reQuest (ARQ)) seem relevant.

		--keith