See a few comments (marked GF)
from the perspective of other transport RFCs, in case this helps
you find text...
-------- Forwarded Message --------
Hi Stewart,
If there are no further objections, I'm
going to declare consensus.
Stewart,
do we need more cycles for this, or is
draft-15 sufficient to address your concerns?
In the general case, delay across a
network path depends not only on distance, but also a number of
variable components such as the route and the level of buffering in
intermediate devices.
Its is more the contending/conflicting traffic
rather than the buffering, or perhaps the time spent in
queues, but “buffering” is a link a transport colloquial
term.
GF: The word being sought might be "queueing" (I
think that buffering is thought of as memory- and hence max
queue).
SB> Queuing ins the word, thank you.
Since our wide-area network paths are best
effort, packet loss is a regular occurrence.
No the best effort Internet experiences this.
There ate many well engineered WAN that do not.
What I am not seeing is clearer text that
distinguishes between user traffic and “engineering” traffic
that is used to make the network work, and between the end
to end traffic and traffic within an AS that may be there
for other purposes (high value service also offered by the
provider) and WANs that are well engineered.
Perhaps we could include a clearer disclaimer
regarding the non-best-effort-internet-end-to-end traffic?
You have some text on this down in section 2 but
it is a bit buried.
Perhaps something early on of the form: This
document is specially concerned with end to end behaviour
over the best effort Internet. As noted in section 2 it may
not me applicable to other types of WAN, or to the traffic
used in affecting the operation of the Internet itself.
GF: Actually, I do think a well-engineering
WAN can be in scope of your spec. The two wrods I was
expecting were "controlled environment" or
"pre-provisioned" capacity, these might not see the same
oath properties. A DC is typically regarded in transport
specs as a "controlled environment".
SB> That works for me as well.
An exception to this rule is if an IETF standardized mechanism
determines that a particular loss is due to a non-congestion
event (e.g., packet corruption).
That is a bit heavy. It should be “a protocol”
there than an IETF standardarized mechanism. The IETF does
not have a monopoly on pre-blessing protocols before they
are deployed.
GF: Unsure myself what is needed - isn't this guidance for
design of protocol mechansims?
SB> .. and if that is the case the words used in the text are way over the top, and may actually cause harm to innocent protocols. SB> There is a bunch of concern in the industry that the IETF is now too illiberal and such words fuel that concern.
Best regards
Stewart
|
