[Mep-dev] TCP Performance Issues [oops]
Michelle
w5nyv@yahoo.com
Sun, 30 Nov 2008 07:24:19 -0800 (PST)
--0-1237434424-1228058659=:567
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
I'm very much=A0looking forward to the rest of it. =0A=0ADo you (all)=A0thi=
nk that the the lack of pressure to make the service pay for itself (as opp=
osed to=A0possibly trying=A0to make the hardware come in at cost)=A0might m=
ake any difference to the design choices of the protocols and the link?=0A=
=0AMost of the=A0examples that I am familiar with spend a lot of time on ac=
counting. Most of=A0the satellite models=A0and most cellular models have to=
keep track=A0of users and=A0how long and how much they use the link, in or=
der to charge for it and=A0make=A0money.=A0=0A=0AMy first=A0inclination is =
that the deletion of all the accounting overhead=A0would=A0do two things - =
it would require some redesign of the link, and it would=A0possibly increas=
e performance due to=A0a lessening of complexity.=0A=0AHowever, it was poin=
ted out to me=A0that relieving the financial accounting side of things does=
n't mean that those same functions are not useful and needed on MEP. So, my=
second inclination is=A0perhaps the accounting=A0functions that are common=
ly=A0seen in satellite and cellular links=A0may=A0end up being required on =
MEP, but implemented for different=A0purposes.=A0Searching, rooms, filters,=
friends lists, modeling,=A0quality of service, and other fun things that a=
re=A0enabled by a rich set of metadata certainly start to sound a lot like =
"accounting".=A0=0A=0AThe level of accountability (authentication and secur=
ity)=A0needs to be explored and discussed. How concerned should we be with =
harmful or unauthorized use? =0A=0ATraditionally, amateur radio is an open =
system that runs on the honor system and is self-policed. I would like to=
=A0remain true to the spirit of amateur radio whenever and wherever that sp=
irit is positive and worth preserving.=A0When considering a digital system =
compared to an analog system,=A0the issues of identification, authenticatio=
n, accounting, and security=A0naturally arise. A model to=A0consider is D-S=
tar, which has=A0repeater registration by call sign. This is a user-entry I=
D. So, to me, it is the equivalent of stating your call sign on the=A0air a=
nd remains=A0a voluntary, honor-system act. =0A=0AI=A0strongly agree with t=
he goal of making MEP a fully functional IP=A0network. That is the baseline=
assumption, and should be=A0explored, challenged, and talked about until w=
e are=A0more than fully convinced it's the right=A0thing to do, where "it" =
is well-defined. This leads directly to identifying the requirements for fu=
lly supporting IP. =0A=0AWhat are the repercussions of amateur radio commun=
icating over a fully=A0functional IP network? What possibly unexpected requ=
irements do we incur upon ourselves by doing so? Are authentication and sec=
urity and identification controversial issues, or are they now so=A0embedde=
d in the communications ecosystem that to remove these functions would be n=
egative? Is the transport protocol truly unaffected by the type of traffic,=
which is a hallmark axiom of layered protocols? In other words, is there a=
nything in particular about amateur radio that would cause a change in the=
=A0requirements for IP? =0A=0AMore soon,=A0-Michelle W5NYV =0A=0A=A0=0A=0A=
=0A=0A________________________________=0AFrom: Timothy J. Salo <salo@saloit=
s.com>=0ATo: mep <mep-dev@uppermeadow.com>=0ASent: Saturday, November 29, 2=
008 5:51:24 PM=0ASubject: Re: [Mep-dev] TCP Performance Issues [oops]=0A=0A=
> Now that I think about it some more, this topic is relevant=0A> to the ME=
P.=A0 First, I will try to outline the broader=0A> controversy and describe=
three contrasting views.=A0 Then,=0A> I will show one area where the MEP p=
roject will probably=0A> need to, in some sense, pick sides.=0A=0AOops.=A0 =
The e-mail escaped before its time.=A0 I will resend it=0Awhen it is comple=
te.=0A=0A-tjs=0A=0A_______________________________________________=0AMep-de=
v mailing list=0AMep-dev@uppermeadow.com=0Ahttp://lists.uppermeadow.com/mai=
lman/listinfo/mep-dev=0A
--0-1237434424-1228058659=:567
Content-Type: text/html; charset=us-ascii
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV></DIV>
<DIV>I'm very much looking forward to the rest of it. </DIV>
<DIV> </DIV>
<DIV>Do you (all) think that the the lack of pressure to make the service pay for itself (as opposed to possibly trying to make the hardware come in at cost) might make any difference to the design choices of the protocols and the link?</DIV>
<DIV> </DIV>
<DIV>Most of the examples that I am familiar with spend a lot of time on accounting. Most of the satellite models and most cellular models have to keep track of users and how long and how much they use the link, in order to charge for it and make money. </DIV>
<DIV> </DIV>
<DIV>My first inclination is that the deletion of all the accounting overhead would do two things - it would require some redesign of the link, and it would possibly increase performance due to a lessening of complexity.</DIV>
<DIV> </DIV>
<DIV>However, it was pointed out to me that relieving the financial accounting side of things doesn't mean that those same functions are not useful and needed on MEP. So, my second inclination is perhaps the accounting functions that are commonly seen in satellite and cellular links may end up being required on MEP, but implemented for different purposes. Searching, rooms, filters, friends lists, modeling, quality of service, and other fun things that are enabled by a rich set of metadata certainly start to sound a lot like "accounting". </DIV>
<DIV> </DIV>
<DIV>The level of accountability (authentication and security) needs to be explored and discussed. How concerned should we be with harmful or unauthorized use? </DIV>
<DIV> </DIV>
<DIV>Traditionally, amateur radio is an open system that runs on the honor system and is self-policed. I would like to remain true to the spirit of amateur radio whenever and wherever that spirit is positive and worth preserving. When considering a digital system compared to an analog system, the issues of identification, authentication, accounting, and security naturally arise. A model to consider is D-Star, which has repeater registration by call sign. This is a user-entry ID. So, to me, it is the equivalent of stating your call sign on the air and remains a voluntary, honor-system act. </DIV>
<DIV> </DIV>
<DIV>I strongly agree with the goal of making MEP a fully functional IP network. That is the baseline assumption, and should be explored, challenged, and talked about until we are more than fully convinced it's the right thing to do, where "it" is well-defined. This leads directly to identifying the requirements for fully supporting IP. </DIV>
<DIV> </DIV>
<DIV>What are the repercussions of amateur radio communicating over a fully functional IP network? What possibly unexpected requirements do we incur upon ourselves by doing so? Are authentication and security and identification controversial issues, or are they now so embedded in the communications ecosystem that to remove these functions would be negative? Is the transport protocol truly unaffected by the type of traffic, which is a hallmark axiom of layered protocols? In other words, is there anything in particular about amateur radio that would cause a change in the requirements for IP? </DIV>
<DIV><BR>More soon, </DIV>-Michelle W5NYV
<DIV></DIV>
<DIV>
<DIV><BR> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: arial, helvetica, sans-serif"><FONT face=Tahoma size=2>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Timothy J. Salo <salo@saloits.com><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> mep <mep-dev@uppermeadow.com><BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Saturday, November 29, 2008 5:51:24 PM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [Mep-dev] TCP Performance Issues [oops]<BR></FONT><BR>> Now that I think about it some more, this topic is relevant<BR>> to the MEP. First, I will try to outline the broader<BR>> controversy and describe three contrasting views. Then,<BR>> I will show one area where the MEP project will probably<BR>> need to, in some sense, pick sides.<BR><BR>Oops. The e-mail escaped before its time. I will resend it<BR>when it is complete.<BR><BR>-tjs<BR><BR>_______________________________________________<BR>Mep-dev mailing list<BR><A href="mailto:Mep-dev@uppermeadow.com"
ymailto="mailto:Mep-dev@uppermeadow.com">Mep-dev@uppermeadow.com</A><BR><A href="http://lists.uppermeadow.com/mailman/listinfo/mep-dev" target=_blank>http://lists.uppermeadow.com/mailman/listinfo/mep-dev</A><BR></DIV></DIV></DIV></div></body></html>
--0-1237434424-1228058659=:567--