Re: [Teas] FW: I-D Action: draft-ietf-teas-rfc3272bis-25.txt

[Bob Briscoe <[e-mail]>]

Adrian,

Thx for the rapid turn-round.

You've dealt with my first main point about how parts of networks are 
designed to be congested by capacity-seeking endpoints. But I noticed 
you've often preceded congestion by 'network'. I don't see what the 
intention of that is. Is some other form of congestion possible in a 
network?

My second main point was about the definition of congestion. I don't 
think it's been grocked. When input exceeds capacity there is certainly 
(very serious) congestion. But very heavy congestion usually occurs when 
input is lower than capacity (or matches it). I.e. sustained input in 
excess of capacity is not a necessary condition for congestion. As 
proof, consider two cases:

  * Consider normal slightly bursty traffic (perhaps just sawtoothing,
    or varying in some other way). At the top of the bursts there are
    losses, so superficially it seems (input - loss = capacity), which
    implies input > capacity. But, the bottom of the bursts are
    typically below capacity, causing a link to be underutilized on
    average by traffic responsive to the losses. The under-utilization
    can easily exceed the loss fraction, such that (nput < capacity)
    still leads to losses and congestion
  * In extremis, consider a link and traffic that support explicit
    congestion notification. Here, there are not even any losses so
    (input <= capacity). But there will still be congestion marking, and
    it can be heavy, implying heavy congestion.


So a better definition of congestion due to responsive traffic is the 
degree at which it 'beats at the door'.

==COMMENTS==
I know I said you can choose not to address the items I highlighted as 
comments, but I feel the following do need some attention...

§1
"...a preponderance of Internet traffic tends to originate in one 
autonomous system and terminate in another,"
Seriously, where's the evidence for this assertion? If there is none, 
it's dangerous to say things like this in an RFC, that could be cited as 
the source of what might be a myth.

"Examples of resources are bandwidth, buffers, and queues"
A queue really is not a resource. A queue is the level of usage of a 
buffer, which is the resource.

==MORE NITS:==
(Just introduced)

while reacting statistical measures -> while reacting to statistical 
measures

"RED provides congestion avoidance which is better than or equivalent to 
traditional Tail-Drop"
Nah. RED's never as bad as Tail-Drop. Always better.

such as capacity management (such as routing control)
(Used to be 'including routing control', but 'such as' is now clunkily 
repeated. My original concern with this sentence was that it said "other 
TE capabilities are also /required/ to deliver acceptable service 
quality" [my emphasis], but making routing an optional example misses 
this point. Better:
"are also required in order to deliver acceptable service quality" -> 
"can also be used to deliver better service quality")

short and medium time scales / long- and medium-time scales
Inconsistent hyphenation. And isn't timescale one word?

BIER-TE. These includes ->  BIER-TE. This includes

>External control  interfaces (stray '>')

When I said "The order of some of the sub-sections seems odd" in §6, I 
meant subsections, not the itemized paragraphs at the start.

Quoting the new para on multipath in the inter-domain section:
                "Layer 4 multipath transport protocols are designed to 
move traffic
                 between domains and to allow control of the selection 
of the paths.
                 To be truly effective, these protocols would require 
visibility of
                 paths and network conditions in other domains, and that 
information
                 may not be available, might not be complete, and is not 
necessarily
                 trustworthy."

  * OK, I know "Layer 4 multipath transport protocols were designed to
    move traffic between domains" were my words, but I should have said
    that was one of the use-cases. In general, L4 mutipath is designed
    to move traffic from more to less congested paths, which can move
    traffic between domains, particularly if the endpoint connects to
    multiple domains.
  * Multipath isn't in general designed to allow control of the
    selection of paths, which is hard for an endpoint - an endpoint can
    generally only select the interfaces at each end in order to
    influence the likely path.
  * The 'To be truly effective...' sentence is unproven criticism; L4
    multipath just blindly uses whatever paths it is given and moves
    traffic away from congestion. So, better utilization balance is an
    emergent property without any need for path visibility.




Bob

On 27/07/2023 17:41, Adrian Farrel wrote:
> All,
>
> The changes here result from several reviews, but mainly from Bob Briscoe's
> very substantial TSV Dir review (for which we are grateful).
>
> The changes are many, but small.
>
> I am not AD, chair, or shepherd, but I think the changes are not
> consequential to the thrust of the document and do not merit a further last
> call. I would, however, welcome people looking at the Diffs.
>
> Cheers,
> Adrian
>
> -----Original Message-----
> From: I-D-Announce<[e-mail]>  On Behalf Of
> [e-mail]
> Sent: 28 July 2023 01:37
> To:[e-mail]
> Cc:[e-mail]
> Subject: I-D Action: draft-ietf-teas-rfc3272bis-25.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Traffic Engineering
> Architecture and Signaling (TEAS) WG of the IETF.
>
>     Title           : Overview and Principles of Internet Traffic Engineering
>     Author          : Adrian Farrel
>     Filename        : draft-ietf-teas-rfc3272bis-25.txt
>     Pages           : 94
>     Date            : 2023-07-27
>
> Abstract:
>     This document describes the principles of traffic engineering (TE) in
>     the Internet.  The document is intended to promote better
>     understanding of the issues surrounding traffic engineering in IP
>     networks and the networks that support IP networking, and to provide
>     a common basis for the development of traffic engineering
>     capabilities for the Internet.  The principles, architectures, and
>     methodologies for performance evaluation and performance optimization
>     of operational networks are also discussed.
>
>     This work was first published as RFC 3272 in May 2002.  This document
>     obsoletes RFC 3272 by making a complete update to bring the text in
>     line with best current practices for Internet traffic engineering and
>     to include references to the latest relevant work in the IETF.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-rfc3272bis/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis-25
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-teas-rfc3272bis-25
>
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories:http://www.ietf.org/shadow.html
> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/