Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 689 (1998)
(USC DC Other)
USC Computer Science Technical Reports, no. 689 (1998)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
The P erformance of a Reliable RequestResp onse T ransp ort Proto col
Nader Salehi Katia Obraczk a Cliord Neuman
Information Sciences Institute
Univ ersit y of Southern California
Admiralt yW ays
Marina del Rey CA v oice fax fsalehi k atia b cn gisiedu
Decem ber
Abstract
This pap er studies the b eha vior of ARDP a requestresp onse transp ort proto col when op erating in a shared
comm unication infrastructure lik e the In ternet Our exp erimen ts demonstrate that ARDP bac ks o in the presence
of congestion y et tries to tak e adv an tage of a v ailable bandwidth Wealso showthat ARDP is w ellb eha v ed when
comp eting for net w ork resources with TCP In tro duction
The Async hronous Reliable Deliv ery Proto col ARDP w as designed to transp ort data b et w een clien ts and serv ers
engaged in requestresp onse st yle of in teractions ARDP pro vides reliable deliv ery without incurring the connec
tion setup and tear do wn o v erhead of TCP The goal is to incur as minim um o v erhead as p ossible in ensuring
reliabilit y in connections that are t ypically short liv ed
ARDP is built atop UDP and w as originally implemen ted as part of the Prosp ero resource disco v ery sys
tem Since then it has ev olv ed in to a standalone proto col used b y services dev elop ed at the USC Information
Sciences Institute ISI suc h as NetCheque and NetCash Because its target clien ts are systems that require
secure data exc hange eg electronic commerce to ols lik e NetCheque and NetCash are go o d examples of suc h
systems ARDP has an option to p erform securit yrelated functions to guaran tee data in tegrit y conden tialit y and authen tication
T o b e able to share net w ork resources with comp eting o ws in a shared comm unication infrastructure lik e
the In ternet ARDP uses TCPst yle congestion con trol mec hanisms This pap er fo cuses on studying the b eha vior
of ARDP when comp eting for net w ork resources with TCPbased o ws Weev aluate howw ell ARDP utilizes
a v ailable bandwidth and howit bac ks o in the presence of comp eting trac to a v oid congesting the net w ork
In our exp erimen tal setup w e use ARDP to carry W eb trac ie HTTP o v er ARDP and compare it against
the original W eb proto col stac k ie HTTP o v er TCP The idea is to use TCPs w elltuned congestion con trol
mec hanisms as a y ardstic k for ARDPs b eha vior
W e organized this pap er as follo ws The next section describ es ARDP in detail In Sections and w e
describ e our exp erimen tal metho dology and presen t the results of our exp erimen ts resp ectiv ely Section places
our w ork in the con text of related w ork Finallyw e presen t our conclusion and our future plans in Section ARDP
Figure sho ws the elds in the ARDP header The ARDP v ersion n um b er app ears in b yte Byte bits sp ecify sp ecial purp ose con texts lik e securitycon text information whic h preceded the pa yload Individual bits
in b yte ha v e dieren t functions from forcing the receiv er to ac kno wledge the arrival ofapac k et Bit A CK
to informing the recipientofac hange in the adv ertised windo w Bit CWIN and to notifying the receiv er of
additional options Bit OFLA GS Byte OFLA G Options allo ws us to carry optional data suchasSA CK
bit v ector to b e explained in P ac k et header length is sp ecied in Byte Eac h unique pac k et is assigned
a sequen tially increasing sequence n um b er stored in Bytes and The p eer informs the recipien t of the largest
con tiguous sequence it has receiv ed b y the use of P eer Receiv ed Thru eld Bytes and All other argumen ts
dep ending on the v alue of Bytes and are stored starting Byte
Version
0
8 15
Context
Unused
ACK Bit
Unused
Seq.
Pkt. Cnt
Priority
Proto. ID
CWIN
Wait
OFLAGS
OFLAG Options Header Length
Connection ID
Packet Sequence Number
Peer Received Thru Number
Start of Arguments (variable)
1
3
5
7
9
11
0
Unused
Unused
Figure ARDP header format
The ARDP clien t asso ciates a bit unique monotonically increasing connection id CID to ev ery request it
generates F or eac h request it gets from clien ts the ARDP serv er generates its o wn connection id b y concatenating
the clien tgenerated CID and the clien ts host por t Since ARDP a v oids connection setup and teardo wn in
order for the clien t to generate unique CIDs it m ust generate requests at a rate not to exceede transactions
per t max seconds where t max is the largest resp onse time for the clien t
The ARDP pac k et header carries information needed bythe o w and congestion con trol mec hanisms These
include the A CK bit CID pac k et sequence n um b er and the p eers receiv ed thru n um b er elds A more detailed
sp ecication of the ARDP proto col can b e found in Flo w and Congestion Con trol Mec hanisms
W e adapted TCPs o w and congestion con trol mec hanisms and incorp orated them in to ARDP In the curren t
implemen tation w e decided not to include TCPs optional delaye d acknow le dgment mec hanism since it tends
to h urt the p erformance of requestresp onse st yle of in teractions esp ecially during slo w start W e implemen ted
the sele ctive acknow le dgment mec hanism SA CK as sp ecied in W e used ARDPs OFLA GS ag and added
the SA CK v ector in the v ariable part of the header SA CK enables detecting and reco veringfromm ultiple pac k et
loss without causing the connection to slo w start and consequen tly without frequen tly cutting the congestion
windo w cw inb y half Similarly to the NETBL T proto col the appropriate bit in the SA CK v ector is set for
eachpac k et receiv ed and is reset to sho w a sequence n um ber gap If the retransmitted pac k et is not lost then the
v ector length is less than or equal to dcw in e If the retransmitted pac k et itself is lost then the v ector length
gro ws to d
RT O cw in
RT T
e b efore the retransmit timer go es o and causes the sender to switc htoslo w start RT O and
RT T are retransmission timeout and round trip time resp ectiv ely Therefore the longer the timeout in terv al
the larger the v ector b ecomes
W e need to men tion that ARDP v the R TO time is not based on the calculation of R TT Instead the R TO
is set to a conguration time v ariable with a gran ularit y of seconds The currentR TO is set to t w o seconds
Slo w Start
The slo w start algorithm is used to gradually increase the amoun t of data a sender injects in to the net w ork
Slo w start is used at the b eginning of a transfer and follo wing pac k et loss detected b y ARDPs retransmission
timer The ARDP sender uses cw in to limit the amoun t of outstanding data injected in to the net w ork ARDPs
slo w start algorithm initializes cw in to pac k ets This will allo w small requests and resp onses to b e transmitted
in their en tiret y without ha ving to w ait for an ac kno wledgmen t
F or eachA CK receiv ed cw in is increased by pac k et Note that unlikeTCP ARDP ac kno wledges pac k et
n um b ers and not n um ber of b ytes receiv ed Once cw in is equal to the slo wstart threshold initially set to the
adv ertised windo w ARDP lea v es slo w start and en ters the congestion a v oidance mo de
Congestion Av oidance
Congestion Av oidance is used to prob e the net w ork for additional bandwidth once congestion is detected
The congestion a v oidance algorithm increases the congestion windo w more conserv ativ ely than the slo w start
algorithm It increases cw in by cw in eachtime an A CK is receiv ed The congestion windo w is increased un til
cw in adv ertised windo w or aw in or a pac k et loss is exp erienced whichin v ok es fast r e c overy F ast Reco v ery
F ast reco v ery has b een suggested byV an Jacobson as a w a y of a v oiding slo w start when a pac k et loss is
detected It uses the A CKs that are still in the pip e to clo c k pac k et transmission F ast reco v ery a v oids en tering
slo w start ev ery time a pac k et is lost It allo ws higher throughput under mo derate congestion esp ecially for large
adv ertised windo ws Ho w ev er if the adv ertised windowisv ery small eg aw in fast reco v ery maynot be as
eectiv e since slo w start ma y reac h the adv ertised windo w faster than fast reco v ery Exp erimen t
Our exp erimen ts consisted of using ARDP to carry W eb trac W e mo died W ebStone a p erformance
benc hmarking to ol to use ARDP as its underlying transp ort mec hanism On one end w e ha v e a mo died
W ebstone clien t sending requests to an ARDP based stripp ed do wn W eb serv er whic h is capable of only receiving
and serving GET messages
W e used the original W eb proto col stac k ie HTTP o v er TCP as a y ardstickagainst whic h w e compare
the p erformance of ARDP W e generated regular W eb trac using the unmo died W ebStone clien t to issue
HTTPo v erTCP requests to an Apac he v serv er
Both W eb serv ers ran on aleeastisiedu a Sun Sparc running Solaris lo cated at ISIs east coast
campus in W ashington DC The W ebStone clien ts ran on joyisiedu
a Sun Ultra running Solaris
lo cated at ISIs w est coast campus in Marina del Rey CA The w orkload used in the exp erimen t regardless of
the transp ort proto col w as a MB le transmitted b y the serv er in resp onse to a clien ts request W e c hose
a reasonably large le so that b oth ARDP and TCP can exit the initial slo w start and op erate in congestion
a v oidance mo de
W e p erformed three dieren t sets of exp erimen ts First w e study the b eha vior of a single ARDP o was a
function of ARDPs adv ertised windo w aw in The goal of this exp erimentw as to mak e sure ARDPs congestion
con trol mec hanism is able to mak e use of a v ailable bandwidth y et bac ks o in the presence of p oten tial congestion
indicated b y pac k et loss W e initially set aw in pac k ets and incremen tit byv epac k ets un til aw in In the second set of exp erimen ts w e studied the beha vior of ARDP in the presence of comp eting TCP
connections
The ARDP and all TCP connections start at the same time The n um ber of comp eting TCP
connections is a p erfect po w er of t w o ranging from one to thirt y t w o Eac h TCP connection adv ertised a
The result of ping messages issued from joyisiedu on at PST
aleeastisiedu PING Statistics
packets transmitted packets received packet loss
roundtrip ms minavgmax Note that b esides the TCP connections weha v e con trol o v er there is also bac kground trac since w e are using shared links in our
exp erimen ts
maxim um congestion windo w of KB W e ran the exp erimen t for ARDPs aw in of and pac k ets although
weonlysho w results for aw in In order to determine whether ARDP has an y signican t impact on TCP
p erformance w e also ran the same exp erimen t without an y comp eting ARDP trac
Finally in phase three w e analyzed the b eha vior of an ARDP o w while comp eting with other ARDP o ws
In this phase we issuedan um b er of sim ultaneous ARDP requests and measured their p erformance The n um ber
connections is a p erfect p o w er of t w o ranging from one to eigh t
In order to assure that our test results w ere not aected b yan y sp ecic net w ork condition w e ran eachphase
of the exp erimen t ten times In most gures w e pro vide the b est w orst and a v erage results In those gures
where there is only one graph w e use the a v erage v alues of the ten runs unless explicitly stated otherwise
Results
Single ARDP Flo w
0
5
10
15
20
25
30
35
40
45
0 10 20 30 40 50 60 70 80 90 100
Congestion Window
Time (sec)
awin 5
awin 10
awin 15
awin 25
awin 40
Figure cw in o v er time
30
40
50
60
70
80
90
100
0 5 10 15 20 25 30 35 40
Response Time (sec)
Advertised Window
Minimum
Maximum
Average
Figure The minim um maxim um and a v erage re
sp onse time as a function of aw in In this set of exp erimen ts w e try to sho w that ARDP is w ell beha v ed it bac ks o when congestion is
detected y et tak es adv an tage of a v ailable bandwidth F or dieren t v alues of aw in Figure sho ws ho w the
congestion windowv aries o v er time W e initially set aw in pac k ets In ev ery subsequentrun w e incremen t
it byv e pac k ets un til aw in W e notice that as long as aw in is b elo w a certain threshold no pak cet is lost
and cw in aw in o v er the en tire run Clearly this threshold is a function of curren t net w ork conditions
F or
higher v alues of aw in pac k ets in this run w eobserv e that the congestion windo w oscillates This indicates
that the congestion windo w tries to adjust to congestion signaled b y pac k et loss and to a v ailable bandwidth
As sho wn in gure the resp onse time decreases as aw in increases up to aw in Increasing aw in bey ond
this threshold ma y result in sligh tly longer resp onse time or in the b est case no impro v emen ts
0
20
40
60
80
100
0 5 10 15 20 25 30 35 40 45
Time (sec)
cwin
pkt # (% 100)
Figure Congestion windo w and pac k et loss aw in 0
20
40
60
80
100
0 5 10 15 20 25 30 35 40 45
Time (sec)
cwin
pkt # (% 100)
Figure Congestion windo w and pac k et loss aw in
Figures and sho w the correlation bet w een the congestion windo w and pac k et loss W e plot congestion
windowas w ell as pac k et loss sequence n um b er mo dulus o v er time F or aw in Figure the connection
slo w starts un til cw in aw in Since there is v ery few pac k et loss cw in holds its v alue throughout the
en tire run except for the losses o ccurred at and s In resp onse to these losses cw in is cut in half and
linearly increases un til it reac hes aw in Ho w ev er setting aw in Figure increases pac k et loss and causes
cw in to adjust to congestion y et trying to tak e adv an tage of a v ailable bandwidth This explains cw ins oscillatory
beha vior
ARDP v ersus TCP
In this phase of the exp erimen ts ARDP comp etes for net w ork resources with TCPW e set ARDPs aw in to pac k ets or KB since the ARDP pac k et is KB somewhat smaller than TCPs maxim um windo w size of
These exp erimen ts w ere run W ed and Th u Dec and late afterno on PST This is probably a time of da ywhenthe
net w ork is not at its p eak load
KB These exp erimen ts w ere run on a w eekda y within pm and pm PST Figures and sho w ARDPs
and TCPs resp onse time as the n um b er of TCP connections increase W e notice that for few er comp eting TCP
connections up to TCP connections TCP and ARDP sho w similar p erformance in terms of resp onse time
As exp ected both ARDP and TCP exp erience p erformance degradation as w e increase the n um ber of TCP
connections ARDP sho ws a relativ ely smaller degradation probably due to the use of selectiveac kno wledgmen t
Figure sho ws ARDPs congestion windo w as the n um b er of TCP connections increase
0
200
400
600
800
1000
1200
1400
0 5 10 15 20 25 30 35
Time (sec)
# of TCP Connections"
Best Response
Worst Response
Average Response
Figure ARDPs resp onse time while comp eting with
TCP 0
200
400
600
800
1000
1200
1400
0 5 10 15 20 25 30 35
Time (sec)
# of TCP Connections
Best Response
Worst Response
Average Response
Figure TCPs p erformance while comp eting with
ARDP Toev aluate ho w ARDP impacts TCP p erformance w e ran the same exp erimen t but this time without com
p eting ARDP trac The TCPs resp onse time graphs sho wn in Figure indicate that ARDP do es not degrade
TCPs p erformance Of course to b e able to quan tify ho w ARDP and TCP in teract w ew ould ha v e to use an
exp erimen tal setup where net w ork conditions suchas bac kground trac can b e con trolled As future w ork w e
plan to sim ulate ARDP using a net w ork sim ulator lik e ns whic h will enable us to study ARDP under v arious
net w ork conditions and w orkload
Figure sho ws n um ber of ARDP pac k ets lost as the n um b er of comp eting TCP connections increase When
correlated with ARDPs cw in v ariation Figure w e observ e that for higher n um b er of comp eting TCP con
nections the n um b er of losses tend to stabilize as cw in reac hes equilibrium
Results from exp erimen ts using ARDPs cw in these results are not presen ted here due to space lim
Note that w e ran eac h exp erimen t times and rep ort the a v erage across the runs In the case of TCPs resp onse time w e rep ort
the b est w orst and a v erage of the a v erage resp onse times
0
5
10
15
20
0 5 10 15 20 25 30 35
Congestion Window
# of TCP Connections"
Figure ARDPs cw in while comp eting with TCP 0
100
200
300
400
500
600
700
800
0 5 10 15 20 25 30 35
# of TCP Connections"
Packet Loss
# of Slow Starts
# of Fast Reoveries
Figure ARDP pac k et loss while comp eting with TCP 0
200
400
600
800
1000
1200
1400
0 5 10 15 20 25 30 35
Time (sec)
# of TCP Connections
Best Response
Worst Response
Average Response
Figure TCPs p erformance without comp etition from ARDP
itations sho w that ARDP p erformed sligh tly b etter This is b ecause ARDP could grab bandwidth whenev er
a v ailable but w ould relinquish it when congestion w as detected
Multiple ARDP Connections
These exp erimen ts showhowm ultiple ARDP connections comp ete for net w ork resources among themselv es w e
used cw in for all the ARDP o ws in these exp erimen ts Figures and sho w ARDP resp onse time
congestion windo w and pac k et loss as the n um b er of sim ultaneous ARDP connections increase These results are
quite similar to the ones in Section whic h suggests that ARDP is indieren t to the nature of comp eting o ws
TCP UDP and adjusts itself based on curren t mere net w ork conditions
0
50
100
150
200
250
300
350
400
0 1 2 3 4 5 6 7 8 9
Time (sec)
# of ARDP connection
Best
Worst
Average
Figure ARDP resp onse time while comp eting with other ARDP o ws
0
5
10
15
20
0 1 2 3 4 5 6 7 8 9
Congestion Window
# of ARDP connection
Figure Avg cw in for ARDP connections
0
50
100
150
200
250
300
350
400
0 1 2 3 4 5 6 7 8 9
# of ARDP connection
Pkt Loss
# of Slow Starts
# of Fast Recoveries
Figure P ac k et loss
Related W ork
The In ternets original proto col suite pro vides b oth a connectionorien ted TCP and a connectionless UDP pro
to col While UDP pro vides b esteort service TCP guaran tees reliable and inorder data deliv ery b y establishing
an endtoend t w ow a y connection b et w een the sender and the receiv er
Besides the actual data transfer TCPs connectionorien ted mo del requires t w o additional phases
Connection setup TCP op ens a connection with a threew a y handshak e whichm ust complete successfully
b efore the transaction starts This adds an extra R TT to the latency of a transaction
Connection teardo wn closing a TCP connection lea v es one or b oth p eers of a connection in TIME W AIT
state whic h lasts for MSL in whic h MSL is the maximum se gment lifetime MSL is dened to b e
seconds TIME W AIT limits the rate of successiv e transactions b et w een the same hostp ort pair
In the case of longliv ed connections the cost of connection setup and teardo wn is amortized o v er the life
of the connection Ho w ev er for requestresp onse st yle of in teractions where connections are shortliv ed TCPs
o v erhead p oses a considerable p erformance hit
Requestresp onse proto cols lik e ARDP representthe middle ground bet w een UDP and TCP An um ber of
reliable but ligh ter w eigh t proto cols ha vebeendev elop ed Indeed in the Decem b er IETF example request
resp onse transp ort proto cols w ere presen ted in the con text of a BOF discussing the requiremen ts for unicast
transp ort T ransaction TCP
T ransaction TCP TTCP a v oids the cost in v olv ed in setting up and tearing a TCP connection byb ypassing
the threew a y handshak e and shortening the delayin TIME W AIT state
TTCP in tro duces a bit incarnation n um b er or c onne ction c ount CC carried as an option in eac hTCP
segmen t Eac h direction of an op en connection is assigned and carries a distinct CC v alue TTCP assigns
monotonically increasing CC v alues to successiv e connections it op ens TTCP is also equipp ed with TCP
Accelerated Op en T A O Under T A O a host cac hes a small amoun t of state p er remote host including the last
v alid CC of the remote host
Tob ypass the threew a y handshak e TTCP clien t uses CC v alues in initial SYN segmen ts If this CC
v alue is larger than the corresp onding cac hed v alue in the serv er host the monotonic prop ert yof CC s ensures
that the SYN segmen t is new and acceptable Otherwise the serv er host is unable to tell whether the segmen t
is an old duplicate or an outof order segmen t therefore it executes a normal threew a y handshaketov alidate
the SYN T AOis th us and optimization and falls bac k to the traditional TCP mec hanism on o ccasions
HTTP
HTTP is a generic requestresp onse applicationla y er proto col whic h has b een designed to accommo date a v ariet y
of applications ranging from do cumentexc hange and managemen t to searc hing and forms pro cessing This request
resp onse st yle of in teraction ho w ev er is undermined since b oth proto cols are la y ered on top of TCPIP T o reduce
the setup and teardo wn costs of shortliv ed transaction p ersisten tconnection HTTP or PHTTP w as
added to HTTP v as the KeepAliv e extension PHTTP uses one TCP connection to carry m ultiple
HTTP requests The goal of PHTTP is to a v oid setup and teardo wn costs and ac hiev e signican tly b etter
p erformance then HTTP whenev er there is a temp oral lo calit y of w eb accesses Ho w ev er further researc hes
ha v e demonstrated that in some cases when either bandwidth or dela y degrades PHTTP sho ws only mo dest
impro v emen ts Moreo v er PHTTP do es not w ork through HTTP pro xies and do es not tak e pip elining of
requests in to accoun t
The W consortium has recen tly prop osed the next generation of HTTP called HTTPNG in whic h they
ha v e suggested transp ort exibilit y It is desirable to run HTTP o v er transp ort proto cols other than TCPlik e
transp ort proto cols The prime motiv e for this exibilit y is that to allo w a gradual shift from TCP another
transp ort proto col eg TTCP Conclusion and F uture W ork
This pap er pro vides a macroscopic p erformance ev aluation of ARDP a reliable requestresp onse transp ort pro
to col Our h yp othesis is that ARDPs TCPst yle congestion con trol mec hanisms ensure that ARDP can co exist
with other proto cols in a shared infrastructure lik e the In ternet
Our exp erimen ts indeed sho w that ARDP is resp onsivetonet w ork congestion y et is able to tak e adv an tage
of a v ailable bandwidth By running exp erimen ts where ARDP and TCP comp ete on an equal basis w esho w ed
that ARDP p erforms comparably to TCP and do es not h urt TCP p erformance
Ho w ev er to understand the details of ho w ARDP and TCPbased trac in teract a microscopic pac k etb y
pac k et study needs to b e conducted Weplanto sim ulate ARDP using a net w ork sim ulator lik e ns whic h
will enable us to study ARDP under v arious net w ork conditions and w orkload
Another item for future w ork is to incorp orate R TT estimation in to ARDPs curren t implemen tation Existing
TCP implemen tations include Karns algorithm whic h can only b e applied to pac k ets not y et retransmitted
Jacobson et al suggested R TTM Round T rip Time Measuremen t whic h includes timestamps in the TCP
option eld of eac h segmen t Wew ould lik e to implementa h ybrid R TT algorithm whic h uses Karns algorithm
for unique pac k ets and R TTM algorithm for duplicate pac k ets If time p ermits w e plan to implementan R TT
estimation mo dule only based on Karns algorithm as w ell and compare the p erformance of these t w o dieren t
R TT estimation sc hemes
Ac kno wledgmen t
Wew ould lik e to thank Bob Braden and Dongho Kim for their v aluable input W e also w an t to to thank Stev en
Augart for his eorts on debugging our ARDP implemen tation
References
B C Neuman The Prosp ero File System A global le system based on the Virtual System Mo del Journal
of Computing Systemsv ol no
B C Neuman and G Medvinsky Requiremen ts for net w ork pa ymen t The NetCheque p ersp ectiv e in
Pr o c e e ding of IEEE Comp c on San Fr ansisc o Marc h
G Medvinsky and B C Neuman NetCash A design for practical electronic currency on the in ternet in
Pr o c e e dings of st the A CM Confer enc e on Computer and Communic ation Se curityNo v em b er
Ardp v proto col sp ecication Marc h Unpublished do cumen t URL
h ttpgostisieduinfoardpardp proto col vh tml
R Braden Requiremen ts for in ternet hosts comm unication la y ers Request for Commen t RF C
Net w ork Information Cen ter Octob er M Allman On the generation and use of tcp ac kno wledgmen ts A CM Computer Communic ation R eview Octob er K F all and S Flo yd Sim ulationbased comparison of taho e reno and sac k tcp Computer Communic ation
R eviewv ol pp July D D Clark M L Lam b ert and L Zhang Netblt A bulk data transfer proto col Request for Commen t
RF C Net w ork Information Cen ter Marc h
V Jacobson and M Karels Congestion aoidance and con trol Pr o c e e dings of the SIGCOMM pp
August
V Jacobson Mo died tcp congestion a v oidenace algorithm email endendin terest mailing list April
G T ren t and M Sak e W ebSTONE The rst generation in HTTP serv er b enc hmarking tec h rep Silicon
Graphics F ebruary S McCanne Ns net w ork sim ulator v ersion Unpublished draft Requiremen ts for unicast transp ortsessions bof Decmeb er F ort y Third IETF meeting Orlando
Florida
R Braden Extending tcp for transactions concepts Request for Commen tRF C Net w ork Information
Cen ter No v em b er V N P admanabhan and J C Mogul Impro ving HTTP latency in Pr o c e e ding of the Se c ond International
World Wide Web Confer enc e Octob er T BernersLee R Fielding and H F ryst yk Hyp ertext transfer proto col h ttp Request for Commen t
RF C Net w ork Information Cen ter Ma y J Heidemann K Obraczk a and J T ouc h Mo deling the p erformance of HTTP o v er sev eral transp ort
proto cols IEEEA CM T r ansactions on Networkingv ol pp Octob er Short and longterm goals for the h ttpng pro ject Marc h WC W orking Draft URL
h ttpwwwworgTRWDHTTPNGgoal s
P Karn and C P artridge Impro ving roundtrip time estimates in reliable transp ort proto cols Computer
Communic ation R eviewv ol pp August V Jacobson R Braden and D Borman Tcp extensions for high p erformance Request for Commen t
RF C Net w ork Information Cen ter Ma y
Abstract (if available)
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 680 (1998)
PDF
USC Computer Science Technical Reports, no. 658 (1997)
PDF
USC Computer Science Technical Reports, no. 684 (1998)
PDF
USC Computer Science Technical Reports, no. 882 (2006)
PDF
USC Computer Science Technical Reports, no. 707 (1999)
PDF
USC Computer Science Technical Reports, no. 735 (2000)
PDF
USC Computer Science Technical Reports, no. 662 (1997)
PDF
USC Computer Science Technical Reports, no. 660 (1997)
PDF
USC Computer Science Technical Reports, no. 652 (1997)
PDF
USC Computer Science Technical Reports, no. 737 (2000)
PDF
USC Computer Science Technical Reports, no. 854 (2005)
PDF
USC Computer Science Technical Reports, no. 595 (1994)
PDF
USC Computer Science Technical Reports, no. 638 (1996)
PDF
USC Computer Science Technical Reports, no. 738 (2000)
PDF
USC Computer Science Technical Reports, no. 651 (1997)
PDF
USC Computer Science Technical Reports, no. 714 (1999)
PDF
USC Computer Science Technical Reports, no. 713 (1999)
PDF
USC Computer Science Technical Reports, no. 690 (1998)
PDF
USC Computer Science Technical Reports, no. 667 (1998)
PDF
USC Computer Science Technical Reports, no. 696 (1999)
Description
Nader Salehi, Katia Obraczka, Clifford Neuman. "The performance of a reliable request-response transport protocol." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 689 (1998).
Asset Metadata
Creator
Neuman, Clifford
(author),
Obraczka, Katia
(author),
Salehi, Nader
(author)
Core Title
USC Computer Science Technical Reports, no. 689 (1998)
Alternative Title
The performance of a reliable request-response transport protocol (
title
)
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Tag
OAI-PMH Harvest
Format
14 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16269691
Identifier
98-689 The Performance of a Reliable Request-Response Transport Protocol (filename)
Legacy Identifier
usc-cstr-98-689
Format
14 pages (extent),technical reports (aat)
Rights
Department of Computer Science (University of Southern California) and the author(s).
Internet Media Type
application/pdf
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Source
20180426-rozan-cstechreports-shoaf
(batch),
Computer Science Technical Report Archive
(collection),
University of Southern California. Department of Computer Science. Technical Reports
(series)
Access Conditions
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Repository Email
csdept@usc.edu
Inherited Values
Title
Computer Science Technical Report Archive
Coverage Temporal
1991/2017
Repository Email
csdept@usc.edu
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/