On Wed, 19 Jul 2000, Reiner Ludwig wrote:
> 1. The subnetwork's retransmission persistency:
>
> A subnetwork's retransmission persistency, i.e., for how long should a link
> layer delay (e.g., in terms of milliseconds) an IP packet in an attempt to
> transmit it over the link before it discards the packet, is an important
> issue for subnetwork designers.
link != subnetwork...
> However, I feel that the draft is too fague
> on this matter:
> "It is important to recognize that a
> subnetwork can go too far in attempting to provide error recovery
> services in the Internet environment. Subnet reliability should be
> "lightweight", i.e., it only has to be "good enough", *not* perfect."
>
> A more concrete alternative would be to say something along the following
> lines:
>
> Subnets that do not distinguish between delay sensitive (e.g., real-time or
> streaming multimedia) and reliable flows (e.g., TCP, Reliable Multicast)
how would you recommend that such subnetworks distinguish between
these two reliably? Aren't 'delay-sensitive' and 'reliable' entirely
orthogonal criteria? (this leads into a discussion of how e.g.
diffserv specifications of same could be interpreted by the subnet -
arguably out of scope, but see discussion of QoS below.)
> should implement a low retransmission persistency (on the order of a few 10
> milliseconds) [IS95] [GSM]. This is necessary to not interfere with the
> delay requirements of delay sensitive flows. On the other hand, subnetworks
> that are capable of separating reliable flows should implement a high
> retransmission persistency for such flows.
hey, that would really kill TCP over satellite's performance; RTT
estimates would be thrown right off. Practically, you're getting in
the way of the ramifications of the end-to-end argument; a lot more
careful text would be needed here.
Or, if we can't come up with text that is careful enough (discussing
subnet error rates and contrasting those with the high reliability
expected by IP-based transports in the light of delay overhead
tradeoffs incurred by the subnet), we opt for saying as little as
possible, above.
(there's some relevant text at the end of the
'Analysis of Link Layer Effects on TCP Performance'
section that could IMO do with moving here.)
> 4. The "Quality of Service, ..." section
>
> Although, I very much like the section and wish we could really implement
> it that way, I don't understand the discussion about the TOS field [RFC1349].
>
> The definitions of the TOS field are obsolete and have been replaced by the
> definition of the differentiated service field [RFC2474 (proposed standard)] :-(
This was discussed on the mailing list some time back; did
the material get lost in editing? dan's on the author list...
See the thread starting
http://pilc.grc.nasa.gov/pilc/list/archive/0774.html
and in particular Dan Grossman's text
http://pilc.grc.nasa.gov/pilc/list/archive/0803.html
(which probably needs updating/trimming, the way diffserv terminology
is going...)
Other stuff:
Referencing/discussing ramifications of Bennett's ToN paper in the
packet reordering section seems like a good idea.
'Packet Reordering is not Pathological Network Behavior' Bennett,
Partridge, Sheetman, IEEE/ACM Transactions on Networking,
December 1999, (7):6, pp. 789-798
Examples of such subnetworks include
ATM, with a single frame size of 48 bytes plus a 5-byte header,
having already referenced AAL encapsulation etc, this example sits
oddly - especially since you're talking about AAL5 several paras
later.
TCP-friendly needs a reference discussing throughput considerations
when first mentioned, and explicitly relating to the 1/sqrt(p) eqn.
Since ACKs are generally smaller than data
segments, TCP can tolerate some asymmetry, but as a general rule
designers of subnetworks should avoid large differences in the
incoming and outgoing bandwidth.
This only becomes a problem when the forward sending: backchannel acks
capacity ratio exceeds 50:1 [*], but it's worth pointing out that
assumptions about which way TCP is flowing are often invalidated by
pesky users. (Hence ADSL networks banning webservers, napster serving
etc.)
[*] R. C. Durst, G. J. Miller, E. J. Travis 'TCP extensions for space
communications', Mobicom '96, Nov '96 - yesyes, conference
papers are not easily obtainable and not much point in referencing
in an RFC - that goes for the MONET paper too.
Using the delayed acknowledgment mechanism {Bra89], which reduces
the number of ACKs transmitted by the receiver by roughly half, can
also improve performance by reducing the congestion on the ACK
channel. These mechanisms should be employed in asymmetric
networks.
Actually, delacks are recommended use anyway; not much point in giving
endhost hints to subnetwork designers who can't control their
endhosts.
The other *criterion* for native multicast *is* a link-layer
filter,
References of the form RFCnnnn are Internet Request for Comments
(RFC) documents available online at www.rfc-editor.org.
little point in saying this _in_ an RFC. "Here's how to get this
document you're already reading".
[APS99] should be [RFC2581]
'Security' section is before references, 'Security Considerations' is
after. odd.
cheers,
L.
<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:24 EST