File: rfc3155.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (899 lines) | stat: -rw-r--r-- 36,388 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                         S. Dawkins
Request for Comments: 3155                                 G. Montenegro
BCP: 50                                                          M. Kojo
Category: Best Current Practice                                V. Magret
                                                               N. Vaidya
                                                             August 2001


        End-to-end Performance Implications of Links with Errors

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document discusses the specific TCP mechanisms that are
   problematic in environments with high uncorrected error rates, and
   discusses what can be done to mitigate the problems without
   introducing intermediate devices into the connection.

Table of Contents

   1.0 Introduction .............................................    2
      1.1 Should you be reading this recommendation?  ...........    3
      1.2 Relationship of this recommendation to PEPs ...........    4
      1.3 Relationship of this recommendation to Link Layer
          Mechanisms.............................................    4
   2.0 Errors and Interactions with TCP Mechanisms ..............    5
      2.1 Slow Start and Congestion Avoidance [RFC2581] .........    5
      2.2 Fast Retransmit and Fast Recovery [RFC2581] ...........    6
      2.3 Selective Acknowledgements [RFC2018, RFC2883] .........    7
   3.0 Summary of Recommendations ...............................    8
   4.0 Topics For Further Work ..................................    9
      4.1 Achieving, and maintaining, large windows .............   10
   5.0 Security Considerations ..................................   11
   6.0 IANA Considerations ......................................   11
   7.0 Acknowledgements .........................................   11
   References ...................................................   11
   Authors' Addresses ...........................................   14
   Full Copyright Statement .....................................   16




Dawkins, et al.          Best Current Practice                  [Page 1]

RFC 3155                PILC - Links with Errors             August 2001


1.0 Introduction

   The rapidly-growing Internet is being accessed by an increasingly
   wide range of devices over an increasingly wide variety of links.  At
   least some of these links do not provide the degree of reliability
   that hosts expect, and this expansion into unreliable links causes
   some Internet protocols, especially TCP [RFC793], to perform poorly.

   Specifically, TCP congestion control [RFC2581], while appropriate for
   connections that lose traffic primarily because of congestion and
   buffer exhaustion, interacts badly with uncorrected errors when TCP
   connections traverse links with high uncorrected error rates.  The
   result is that sending TCPs may spend an excessive amount of time
   waiting for acknowledgement that do not arrive, and then, although
   these losses are not due to congestion-related buffer exhaustion, the
   sending TCP transmits at substantially reduced traffic levels as it
   probes the network to determine "safe" traffic levels.

   This document does not address issues with other transport protocols,
   for example, UDP.

   Congestion avoidance in the Internet is based on an assumption that
   most packet losses are due to congestion.  TCP's congestion avoidance
   strategy treats the absence of acknowledgement as a congestion
   signal.  This has worked well since it was introduced in 1988 [VJ-
   DCAC], because most links and subnets have relatively low error rates
   in normal operation, and congestion is the primary cause of loss in
   these environments.  However, links and subnets that do not enjoy low
   uncorrected error rates are becoming more prevalent in parts of the
   Internet.  In particular, these include terrestrial and satellite
   wireless links.  Users relying on traffic traversing these links may
   see poor performance because their TCP connections are spending
   excessive time in congestion avoidance and/or slow start procedures
   triggered by packet losses due to transmission errors.

   The recommendations in this document aim at improving utilization of
   available path capacity over such high error-rate links in ways that
   do not threaten the stability of the Internet.

   Applications use TCP in very different ways, and these have
   interactions with TCP's behavior [RFC2861].  Nevertheless, it is
   possible to make some basic assumptions about TCP flows.
   Accordingly, the mechanisms discussed here are applicable to all uses
   of TCP, albeit in varying degrees according to different scenarios
   (as noted where appropriate).






Dawkins, et al.          Best Current Practice                  [Page 2]

RFC 3155                PILC - Links with Errors             August 2001


   This recommendation is based on the explicit assumption that major
   changes to the entire installed base of routers and hosts are not a
   practical possibility.  This constrains any changes to hosts that are
   directly affected by errored links.

1.1 Should you be reading this recommendation?

   All known subnetwork technologies provide an "imperfect" subnetwork
   service - the bit error rate is non-zero.  But there's no obvious way
   for end stations to tell the difference between packets discarded due
   to congestion and losses due to transmission errors.

   If a directly-attached subnetwork is reporting transmission errors to
   a host, these reports matter, but we can't rely on explicit
   transmission error reports to both hosts.

   Another way of deciding if a subnetwork should be considered to have
   a "high error rate" is by appealing to mathematics.

   An approximate formula for the TCP Reno response function is given in
   [PFTK98]:

                                s
   T = --------------------------------------------------
       RTT*sqrt(2p/3) + tRTO*(3*sqrt(3p/8))*p*(1 + 32p**2)

   where

       T = the sending rate in bytes per second
       s = the packet size in bytes
       RTT = round-trip time in seconds
       tRTO = TCP retransmit timeout value in seconds
       p = steady-state packet loss rate

   If one plugs in an observed packet loss rate, does the math and then
   sees predicted bandwidth utilization that is greater than the link
   speed, the connection will not benefit from recommendations in this
   document, because the level of packet losses being encountered won't
   affect the ability of TCP to utilize the link.  If, however, the
   predicted bandwidth is less than the link speed, packet losses are
   affecting the ability of TCP to utilize the link.

   If further investigation reveals a subnetwork with significant
   transmission error rates, the recommendations in this document will
   improve the ability of TCP to utilize the link.






Dawkins, et al.          Best Current Practice                  [Page 3]

RFC 3155                PILC - Links with Errors             August 2001


   A few caveats are in order, when doing this calculation:

   (1)   the RTT is the end-to-end RTT, not the link RTT.
   (2)   Max(1.0, 4*RTT) can be substituted as a simplification for
         tRTO.
   (3)   losses may be bursty - a loss rate measured over an interval
         that includes multiple bursty loss events may understate the
         impact of these loss events on the sending rate.

1.2 Relationship of this recommendation to PEPs

   This document discusses end-to-end mechanisms that do not require
   TCP-level awareness by intermediate nodes.  This places severe
   limitations on what the end nodes can know about the nature of losses
   that are occurring between the end nodes.  Attempts to apply
   heuristics to distinguish between congestion and transmission error
   have not been successful [BV97, BV98, BV98a].  This restriction is
   relaxed in an informational document on Performance Enhancing Proxies
   (PEPs) [RFC3135]. Because PEPs can be placed on boundaries where
   network characteristics change dramatically, PEPs have an additional
   opportunity to improve performance over links with uncorrected
   errors.

   However, generalized use of PEPs contravenes the end-to-end principle
   and is highly undesirable given their deleterious implications, which
   include the following: lack of fate sharing (a PEP adds a third point
   of failure besides the endpoints themselves), end-to-end reliability
   and diagnostics, preventing end-to-end security (particularly network
   layer security such as IPsec), mobility (handoffs are much more
   complex because state must be transferred), asymmetric routing (PEPs
   typically require being on both the forward and reverse paths of a
   connection), scalability (PEPs add more state to maintain), QoS
   transparency and guarantees.

   Not every type of PEP has all the drawbacks listed above.
   Nevertheless, the use of PEPs may have very serious consequences
   which must be weighed carefully.

1.3 Relationship of this recommendation to Link Layer Mechanisms

   This recommendation is for use with TCP over subnetwork technologies
   (link layers) that have already been deployed.  Subnetworks that are
   intended to carry Internet protocols, but have not been completely
   specified are the subject of a best common practices (BCP) document
   which has been developed or is under development by the Performance






Dawkins, et al.          Best Current Practice                  [Page 4]

RFC 3155                PILC - Links with Errors             August 2001


   Implications of Link Characteristics WG (PILC) [PILC-WEB].  This last
   document is aimed at designers who still have the opportunity to
   reduce the number of uncorrected errors TCP will encounter.

2.0 Errors and Interactions with TCP Mechanisms

   A TCP sender adapts its use of network path capacity based on
   feedback from the TCP receiver.  As TCP is not able to distinguish
   between losses due to congestion and losses due to uncorrected
   errors, it is not able to accurately determine available path
   capacity in the presence of significant uncorrected errors.

2.1 Slow Start and Congestion Avoidance [RFC2581]

   Slow Start and Congestion Avoidance [RFC2581] are essential to the
   current stability of the Internet.  These mechanisms were designed to
   accommodate networks that do not provide explicit congestion
   notification.  Although experimental mechanisms such as [RFC2481] are
   moving in the direction of explicit congestion notification, the
   effect of ECN on ECN-aware TCPs is essentially the same as the effect
   of implicit congestion notification through congestion-related loss,
   except that ECN provides this notification before packets are lost,
   and must then be retransmitted.

   TCP connections experiencing high error rates on their paths interact
   badly with Slow Start and with Congestion Avoidance, because high
   error rates make the interpretation of losses ambiguous - the sender
   cannot know whether detected losses are due to congestion or to data
   corruption.  TCP makes the "safe" choice and assumes that the losses
   are due to congestion.

      -  Whenever sending TCPs receive three out-of-order
         acknowledgement, they assume the network is mildly congested
         and invoke fast retransmit/fast recovery (described below).

      -  Whenever TCP's retransmission timer expires, the sender assumes
         that the network is congested and invokes slow start.

      -  Less-reliable link layers often use small link MTUs.  This
         slows the rate of increase in the sender's window size during
         slow start, because the sender's window is increased in units
         of segments.  Small link MTUs alone don't improve reliability.
         Path MTU discovery [RFC1191] must also be used to prevent
         fragmentation.  Path MTU discovery allows the most rapid
         opening of the sender's window size during slow start, but a
         number of round trips may still be required to open the window
         completely.




Dawkins, et al.          Best Current Practice                  [Page 5]

RFC 3155                PILC - Links with Errors             August 2001


   Recommendation: Any standards-conformant TCP will implement Slow
   Start and Congestion Avoidance, which are MUSTs in STD 3 [RFC1122].
   Recommendations in this document will not interfere with these
   mechanisms.

2.2 Fast Retransmit and Fast Recovery [RFC2581]

   TCP provides reliable delivery of data as a byte-stream to an
   application, so that when a segment is lost (whether due to either
   congestion or transmission loss), the receiver TCP implementation
   must wait to deliver data to the receiving application until the
   missing data is received.  The receiver TCP implementation detects
   missing segments by segments arriving with out-of-order sequence
   numbers.

   TCPs should immediately send an acknowledgement when data is received
   out-of-order [RFC2581], providing the next expected sequence number
   with no delay, so that the sender can retransmit the required data as
   quickly as possible and the receiver can resume delivery of data to
   the receiving application.  When an acknowledgement carries the same
   expected sequence number as an acknowledgement that has already been
   sent for the last in-order segment received, these acknowledgement
   are called "duplicate ACKs".

   Because IP networks are allowed to reorder packets, the receiver may
   send duplicate acknowledgments for segments that arrive out of order
   due to routing changes, link-level retransmission, etc.  When a TCP
   sender receives three duplicate ACKs, fast retransmit [RFC2581]
   allows it to infer that a segment was lost.  The sender retransmits
   what it considers to be this lost segment without waiting for the
   full retransmission timeout, thus saving time.

   After a fast retransmit, a sender halves its congestion window and
   invokes the fast recovery [RFC2581] algorithm, whereby it invokes
   congestion avoidance from a halved congestion window, but does not
   invoke slow start from a one-segment congestion window as it would do
   after a retransmission timeout.  As the sender is still receiving
   dupacks, it knows the receiver is receiving packets sent, so the full
   reduction after a timeout when no communication has been received is
   not called for.  This relatively safe optimization also saves time.

   It is important to be realistic about the maximum throughput that TCP
   can have over a connection that traverses a high error-rate link.  In
   general, TCP will increase its congestion window beyond the delay-
   bandwidth product.  TCP's congestion avoidance strategy is additive-
   increase, multiplicative-decrease, which means that if additional
   errors are encountered before the congestion window recovers
   completely from a 50-percent reduction, the effect can be a "downward



Dawkins, et al.          Best Current Practice                  [Page 6]

RFC 3155                PILC - Links with Errors             August 2001


   spiral" of the congestion window due to additional 50-percent
   reductions.  Even using Fast Retransmit/Fast Recovery, the sender
   will halve the congestion window each time a window contains one or
   more segments that are lost, and will re-open the window by one
   additional segment for each congestion window's worth of
   acknowledgement received.

   If a connection's path traverses a link that loses one or more
   segments during this recovery period, the one-half reduction takes
   place again, this time on a reduced congestion window - and this
   downward spiral will continue to hold the congestion window below
   path capacity until the connection is able to recover completely by
   additive increase without experiencing loss.

   Of course, no downward spiral occurs if the error rate is constantly
   high and the congestion window always remains small; the
   multiplicative-increase "slow start" will be exited early, and the
   congestion window remains low for the duration of the TCP connection.
   In links with high error rates, the TCP window may remain rather
   small for long periods of time.

   Not all causes of small windows are related to errors.  For example,
   HTTP/1.0 commonly closes TCP connections to indicate boundaries
   between requested resources.  This means that these applications are
   constantly closing "trained" TCP connections and opening "untrained"
   TCP connections which will execute slow start, beginning with one or
   two segments.  This can happen even with HTTP/1.1, if webmasters
   configure their HTTP/1.1 servers to close connections instead of
   waiting to see if the connection will be useful again.

   A small window - especially a window of less than four segments -
   effectively prevents the sender from taking advantage of Fast
   Retransmits.  Moreover, efficient recovery from multiple losses
   within a single window requires adoption of new proposals (NewReno
   [RFC2582]).

   Recommendation: Implement Fast Retransmit and Fast Recovery at this
   time.  This is a widely-implemented optimization and is currently at
   Proposed Standard level.  [RFC2488] recommends implementation of Fast
   Retransmit/Fast Recovery in satellite environments.

2.3 Selective Acknowledgements [RFC2018, RFC2883]

   Selective Acknowledgements [RFC2018] allow the repair of multiple
   segment losses per window without requiring one (or more) round-trips
   per loss.





Dawkins, et al.          Best Current Practice                  [Page 7]

RFC 3155                PILC - Links with Errors             August 2001


   [RFC2883] proposes a minor extension to SACK that allows receiving
   TCPs to provide more information about the order of delivery of
   segments, allowing "more robust operation in an environment of
   reordered packets, ACK loss, packet replication, and/or early
   retransmit timeouts".  Unless explicitly stated otherwise, in this
   document, "Selective Acknowledgements" (or "SACK") refers to the
   combination of [RFC2018] and [RFC2883].

   Selective acknowledgments are most useful in LFNs ("Long Fat
   Networks") because of the long round trip times that may be
   encountered in these environments, according to Section 1.1 of
   [RFC1323], and are especially useful if large windows are required,
   because there is a higher probability of multiple segment losses per
   window.

   On the other hand, if error rates are generally low but occasionally
   higher due to channel conditions, TCP will have the opportunity to
   increase its window to larger values during periods of improved
   channel conditions between bursts of errors.  When bursts of errors
   occur, multiple losses within a window are likely to occur.  In this
   case, SACK would provide benefits in speeding the recovery and
   preventing unnecessary reduction of the window size.

   Recommendation: Implement SACK as specified in [RFC2018] and updated
   by [RFC2883], both Proposed Standards.  In cases where SACK cannot be
   enabled for both sides of a connection, TCP senders may use NewReno
   [RFC2582] to better handle partial ACKs and multiple losses within a
   single window.

3.0 Summary of Recommendations

   The Internet does not provide a widely-available loss feedback
   mechanism that allows TCP to distinguish between congestion loss and
   transmission error.  Because congestion affects all traffic on a path
   while transmission loss affects only the specific traffic
   encountering uncorrected errors, avoiding congestion has to take
   precedence over quickly repairing transmission errors.  This means
   that the best that can be achieved without new feedback mechanisms is
   minimizing the amount of time that is spent unnecessarily in
   congestion avoidance.

   The Fast Retransmit/Fast Recovery mechanism allows quick repair of
   loss without giving up the safety of congestion avoidance.  In order
   for Fast Retransmit/Fast Recovery to work, the window size must be
   large enough to force the receiver to send three duplicate
   acknowledgments before the retransmission timeout interval expires,
   forcing full TCP slow-start.




Dawkins, et al.          Best Current Practice                  [Page 8]

RFC 3155                PILC - Links with Errors             August 2001


   Selective Acknowledgements (SACK) extend the benefit of Fast
   Retransmit/Fast Recovery to situations where multiple segment losses
   in the window need to be repaired more quickly than can be
   accomplished by executing Fast Retransmit for each segment loss, only
   to discover the next segment loss.

   These mechanisms are not limited to wireless environments.  They are
   usable in all environments.

4.0 Topics For Further Work

   "Limited Transmit" [RFC3042] has been specified as an optimization
   extending Fast Retransmit/Fast Recovery for TCP connections with
   small congestion windows that will not trigger three duplicate
   acknowledgments.  This specification is deemed safe, and it also
   provides benefits for TCP connections that experience a large amount
   of packet (data or ACK) loss.  Implementors should evaluate this
   standards track specification for TCP in loss environments.

   Delayed Duplicate Acknowledgements [MV97, VMPM99] attempts to prevent
   TCP-level retransmission when link-level retransmission is still in
   progress, adding additional traffic to the network.  This proposal is
   worthy of additional study, but is not recommended at this time,
   because we don't know how to calculate appropriate amounts of delay
   for an arbitrary network topology.

   It is not possible to use explicit congestion notification [RFC2481]
   as a surrogate for explicit transmission error notification (no
   matter how much we wish it was!).  Some mechanism to provide explicit
   notification of transmission error would be very helpful.  This might
   be more easily provided in a PEP environment, especially when the PEP
   is the "first hop" in a connection path, because current checksum
   mechanisms do not distinguish between transmission error to a payload
   and transmission error to the header.  Furthermore, if the header is
   damaged, sending explicit transmission error notification to the
   right endpoint is problematic.

   Losses that take place on the ACK stream, especially while a TCP is
   learning network characteristics, can make the data stream quite
   bursty (resulting in losses on the data stream, as well).  Several
   ways of limiting this burstiness have been proposed, including TCP
   transmit pacing at the sender and ACK rate control within the
   network.

   "Appropriate Byte Counting" (ABC) [ALL99], has been proposed as a way
   of opening the congestion window based on the number of bytes that
   have been successfully transfered to the receiver, giving more
   appropriate behavior for application protocols that initiate



Dawkins, et al.          Best Current Practice                  [Page 9]

RFC 3155                PILC - Links with Errors             August 2001


   connections with relatively short packets.  For SMTP [RFC2821], for
   instance, the client might send a short HELO packet, a short MAIL
   packet, one or more short RCPT packets, and a short DATA packet -
   followed by the entire mail body sent as maximum-length packets.  An
   ABC TCP sender would not use ACKs for each of these short packets to
   increase the congestion window to allow additional full-length
   packets.  ABC is worthy of additional study, but is not recommended
   at this time, because ABC can lead to increased burstiness when
   acknowledgments are lost.

4.1 Achieving, and maintaining, large windows

   The recommendations described in this document will aid TCPs in
   injecting packets into ERRORed connections as fast as possible
   without destabilizing the Internet, and so optimizing the use of
   available bandwidth.

   In addition to these TCP-level recommendations, there is still
   additional work to do at the application level, especially with the
   dominant application protocol on the World Wide Web, HTTP.

   HTTP/1.0 (and earlier versions) closes TCP connections to signal a
   receiver that all of a requested resource had been transmitted.
   Because WWW objects tend to be small in size [MOGUL], TCPs carrying
   HTTP/1.0 traffic experience difficulty in "training" on available
   path capacity (a substantial portion of the transfer has already
   happened by the time TCP exits slow start).

   Several HTTP modifications have been introduced to improve this
   interaction with TCP ("persistent connections" in HTTP/1.0, with
   improvements in HTTP/1.1 [RFC2616]).  For a variety of reasons, many
   HTTP interactions are still HTTP/1.0-style - relatively short-lived.

   Proposals which reuse TCP congestion information across connections,
   like TCP Control Block Interdependence [RFC2140], or the more recent
   Congestion Manager [BS00] proposal, will have the effect of making
   multiple parallel connections impact the network as if they were a
   single connection, "trained" after a single startup transient.  These
   proposals are critical to the long-term stability of the Internet,
   because today's users always have the choice of clicking on the
   "reload" button in their browsers and cutting off TCP's exponential
   backoff - replacing connections which are building knowledge of the
   available bandwidth with connections with no knowledge at all.








Dawkins, et al.          Best Current Practice                 [Page 10]

RFC 3155                PILC - Links with Errors             August 2001


5.0 Security Considerations

   A potential vulnerability introduced by Fast Retransmit/Fast Recovery
   is (as pointed out in [RFC2581]) that an attacker may force TCP
   connections to grind to a halt, or, more dangerously, behave more
   aggressively.  The latter possibility may lead to congestion
   collapse, at least in some regions of the network.

   Selective acknowledgments is believed to neither strengthen nor
   weaken TCP's current security properties [RFC2018].

   Given that the recommendations in this document are performed on an
   end-to-end basis, they continue working even in the presence of end-
   to-end IPsec.  This is in direct contrast with mechanisms such as
   PEP's which are implemented in intermediate nodes (section 1.2).

6.0 IANA Considerations

   This document is a pointer to other, existing IETF standards.  There
   are no new IANA considerations.

7.0 Acknowledgements

   This recommendation has grown out of RFC 2757, "Long Thin Networks",
   which was in turn based on work done in the IETF TCPSAT working
   group.  The authors are indebted to the active members of the PILC
   working group.  In particular, Mark Allman and Lloyd Wood gave us
   copious and insightful feedback, and Dan Grossman and Jamshid Mahdavi
   provided text replacements.

References

   [ALL99]    M. Allman, "TCP Byte Counting Refinements," ACM Computer
              Communication Review, Volume 29, Number 3, July 1999.
              http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
              99.html

   [BS00]     Balakrishnan, H. and S. Seshan, "The Congestion Manager",
              RFC 3124, June 2001.

   [BV97]     S. Biaz and N. Vaidya, "Using End-to-end Statistics to
              Distinguish Congestion and Corruption Losses: A Negative
              Result," Texas A&M University, Technical Report 97-009,
              August 18, 1997.







Dawkins, et al.          Best Current Practice                 [Page 11]

RFC 3155                PILC - Links with Errors             August 2001


   [BV98]     S. Biaz and N. Vaidya, "Sender-Based heuristics for
              Distinguishing Congestion Losses from Wireless
              Transmission Losses," Texas A&M University, Technical
              Report 98-013, June 1998.

   [BV98a]    S. Biaz and N. Vaidya, "Discriminating Congestion Losses
              from Wireless Losses using Inter-Arrival Times at the
              Receiver," Texas A&M University, Technical Report 98-014,
              June 1998.

   [MOGUL]    "The Case for Persistent-Connection HTTP", J. C. Mogul,
              Research Report 95/4, May 1995. Available as
              http://www.research.digital.com/wrl/techreports/abstracts/
              95.4.html

   [MV97]     M. Mehta and N. Vaidya, "Delayed Duplicate-
              Acknowledgements:  A Proposal to Improve Performance of
              TCP on Wireless Links," Texas A&M University, December 24,
              1997.  Available at
              http://www.cs.tamu.edu/faculty/vaidya/mobile.html

   [PILC-WEB] http://pilc.grc.nasa.gov/

   [PFTK98]   Padhye, J., Firoiu, V., Towsley, D. and J.Kurose, "TCP
              Throughput: A simple model and its empirical validation",
              SIGCOMM Symposium on Communications Architectures and
              Protocols, August 1998.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC2821]  Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
              2821, April 2001.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts --
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1191]  Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
              November 1990.

   [RFC1323]  Jacobson, V., Braden, R. and D. Borman. "TCP Extensions
              for High Performance", RFC 1323, May 1992.

   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow "TCP
              Selective Acknowledgment Options", RFC 2018, October 1996.

   [RFC2140]  Touch, J., "TCP Control Block Interdependence", RFC 2140,
              April 1997.



Dawkins, et al.          Best Current Practice                 [Page 12]

RFC 3155                PILC - Links with Errors             August 2001


   [RFC2309]  Braden, B., Clark, D., Crowcrfot, J., Davie, B., Deering,
              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
              Partridge, C., Peterson, L., Ramakrishnan, K., Shecker,
              S., Wroclawski, J. and L, Zhang, "Recommendations on Queue
              Management and Congestion Avoidance in the Internet", RFC
              2309, April 1998.

   [RFC2481]  Ramakrishnan K. and S. Floyd, "A Proposal to add Explicit
              Congestion Notification (ECN) to IP", RFC 2481, January
              1999.

   [RFC2488]  Allman, M., Glover, D. and L. Sanchez. "Enhancing TCP Over
              Satellite Channels using Standard Mechanisms", BCP 28, RFC
              2488, January 1999.

   [RFC2581]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
              Control", RFC 2581, April 1999.

   [RFC2582]  Floyd, S. and T. Henderson, "The NewReno Modification to
              TCP's Fast Recovery Algorithm", RFC 2582, April 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2861]  Handley, H., Padhye, J. and S., Floyd, "TCP Congestion
              Window Validation", RFC 2861, June 2000.

   [RFC2883]  Floyd, S., Mahdavi, M., Mathis, M. and M. Podlosky, "An
              Extension to the Selective Acknowledgement (SACK) Option
              for TCP", RFC 2883, August 1999.

   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery", RFC
              2923, September 2000.

   [RFC3042]  Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing
              TCP's Loss Recovery Using Limited Transmit", RFC 3042,
              January, 2001.

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135, June 2001.

   [VJ-DCAC]  Jacobson, V., "Dynamic Congestion Avoidance / Control" e-
              mail dated February 11, 1988, available from
              http://www.kohala.com/~rstevens/vanj.88feb11.txt





Dawkins, et al.          Best Current Practice                 [Page 13]

RFC 3155                PILC - Links with Errors             August 2001


   [VMPM99]   N. Vaidya, M. Mehta, C. Perkins, and G. Montenegro,
              "Delayed Duplicate Acknowledgements: A TCP-Unaware
              Approach to Improve Performance of TCP over Wireless,"
              Technical Report 99-003, Computer Science Dept., Texas A&M
              University, February 1999. Also, to appear in Journal of
              Wireless Communications and Wireless Computing (Special
              Issue on Reliable Transport Protocols for Mobile
              Computing).

Authors' Addresses

   Questions about this document may be directed to:

   Spencer Dawkins
   Fujitsu Network Communications
   2801 Telecom Parkway
   Richardson, Texas 75082

   Phone: +1-972-479-3782
   EMail: spencer.dawkins@fnc.fujitsu.com


   Gabriel E. Montenegro
   Sun Microsystems
   Laboratories, Europe
   29, chemin du Vieux Chene
   38240 Meylan
   FRANCE

   Phone: +33 476 18 80 45
   EMail: gab@sun.com


   Markku Kojo
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 HELSINKI
   Finland

   Phone: +358-9-1914-4179
   EMail: kojo@cs.helsinki.fi









Dawkins, et al.          Best Current Practice                 [Page 14]

RFC 3155                PILC - Links with Errors             August 2001


   Vincent Magret
   Alcatel Internetworking, Inc.
   26801 W. Agoura road
   Calabasas, CA, 91301

   Phone: +1 818 878 4485
   EMail: vincent.magret@alcatel.com


   Nitin H. Vaidya
   458 Coodinated Science Laboratory, MC-228
   1308 West Main Street
   Urbana, IL 61801

   Phone: 217-265-5414
   E-mail: nhv@crhc.uiuc.edu



































Dawkins, et al.          Best Current Practice                 [Page 15]

RFC 3155                PILC - Links with Errors             August 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Dawkins, et al.          Best Current Practice                 [Page 16]