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

[Bob Briscoe <[e-mail]>]

Adrian,

I just realized I overlooked two earlier emails from you. I'll take to 
my bed now and look tomorrow. But apologies if anything I said in my 
review follow-up had already been addressed in these two.


Bob

On 28/07/2023 02:08, Bob Briscoe wrote:
> 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/

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