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

[Adrian Farrel <[e-mail]>]

Hi again,

 

This is the other thread to complete answering your responses to my updates after your review.

 

> 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?

 

We have partly covered this in the other thread.

There is a definition included in the document, and the term “network congestion” makes a distinction from “demand-side congestion” or “input congestion”.


> 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 (input < capacity) still leads to losses

>    and congestion

 

So, as with everything in life, it depends on the time interval over which you are measuring. It is no comfort to the user to say “Measured over 24 hours, there was no congestion (input was less than capacity), so suck it up.” The user cares about periods when input exceeds capacity to such an extent that there is unacceptable delay or packet loss.

 

> • 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.

 

If congestion is defined as something that triggers ECN, but which does not negatively impact the traffic flow, then calling it congestion or heavy congestion is just confusing.

 

Hence, the definition of Congestion we are using is general and wide to encompass the varying concept you have described, but the definition of Network Congestion explicitly states: “Congestion within the network at a specific node or a specific link that is sufficiently extreme that it results in unacceptable queuing delay or packet loss.” Thus we distinguish between the general concept and the type of congestion that TE seeks to circumvent.

 

> 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.



I think this is covered in the other thread.


> "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.

 

This is covered in the other thread.

Queues are instantiated. Buffers are placed on queues. Both are resources.


> ==MORE NITS:==
> (Just introduced)
>
> while reacting statistical measures -> while reacting to statistical measures



Ack

 

> "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.



Surely, as packet arrival exceeds RED’s drop rate, the buffers approach depleted until there are no more buffers and RED’s drop probability is 1. At this point, RED equates to Tail-Drop.

 

> 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")



Agree about the clunky. Fixed.

You misquoted originally, although quoted correctly in the proposed change.

“…are required to…” would mean that the other TE capabilities MUST deliver acceptable service quality. But it doesn’t say that.

“…can also be used…” means that Diffserv can deliver acceptable service quality. Which is not the case.

“…are also required in order to…” means that if you want acceptable service quality then you will need other TE capabilities. Which is what we intended.

But there is a suite of tools which can be picked from to reach the acceptable service quality.

 

> short and medium time scales / long- and medium-time scales

 

Yes


> Inconsistent hyphenation. And isn't timescale one word?



Oh, yes. Widespread change.

 

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



Hah! >>> These include  (the implications)

 

> >External control interfaces (stray '>')



Ack

 

> 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.

 

Understood. I’ve looked again, but the ordering seems good to me.


> 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.

 

In the first bullet you say move traffic from one path to another. But then you say no control of which path is used. That’s a contradiction.

 

I think that the text as written scopes:

*	Not just designed for moving traffic between domains
*	Allowing some choice of which path is chosen

 

> • 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.

 

So L4 multipath is reactive and “blindly” moves traffic around until it hits a non-congested path (or, indeed, thrashes between a set of congested paths).

So, to be more effective, you would want to be able to see the conditions within networks and be able to select paths more wisely (less blindly).


Cheers,

Adrian