Subject: Re: [PANRG] RG Last Call for draft-irtf-panrg-what-not-to-do-05

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 6 Jan 2020 18:47:04 +0000

Reply [MS] regarding Section 5.3, as the orginial author of that section

…

Section 5.3:

"[…] In these cases, a sender cannot easily determine an appropriate
initial sending rate, given the lack of information about the path"
What does "these" refer to here? Isn't this a general problem?

[MS] That Looks like an editorial issue that results from a sentence that was added later. My originial wording was along the lines of …

   Quick-Start [RFC4782<https://tools.ietf.org/html/rfc4782>] is an Experimental TCP extension that leverages

   support from the routers on the path to determine an allowed initial

   sending rate for a path through the Internet, either at the start of

   data transfers or after idle periods. <additional sentence on DCCP> In

   these cases, a sender cannot easily determine an appropriate initial

   sending rate, given the lack of information about the path.

[MS] So, in my original text this „in these cases“ has referred to the previous sentence. I think the additional sentences on DCCP that was added afterwards in the middle could be moved e.g. to the end of the paragraph.

"One challenge is synchronization of information between different
packets […]"
What does synchronization mean here? That a router signals for two flows
that there's capacity?

[MS] Yes, albeit the issue is actually related to internals of a router. The full paragraph talks about parallelism of packet processing inside the fast path of routers:

      For scalable router fast path implementation, it is important to

      enable parallel processing of packets, as this is a widely used

      method e.g. in network processors.  One challenge is

      synchronization of information between different packets, which

      should be avoided as much as possible.

[MS] As an admission control like Quick-Start has to change packet header fields according to available capacity, dynamically changing state information has to be kept consistent between the tasks/cores that forward IP packets in the router, in order to avoid inconsistencies and capacity overbooking. This runs into the typical issues of state synchronization in massively parallel systems and doesn’t scale well. Maybe a better wording would be: „One challenge is synchronization of information between different packets that are processed in parallel […]“

Michael

PS: I learnt myself a lot about the _engineering_ issues of path awareness when looking into actual routers and commercial network management software.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Jan 2020 18:09:30 -0600

Hi, Michael,

Thank you for your helpful suggestions - I reflected them in -06.

Spencer

On Mon, Jan 6, 2020 at 12:47 PM Scharf, Michael <
[email-masked]> wrote:

> [MS] That Looks like an editorial issue that results from a sentence that
> was added later. My originial wording was along the lines of …
>
>
>
>    Quick-Start [RFC4782 <https://tools.ietf.org/html/rfc4782>] is an Experimental TCP extension that leverages
>
> [MS] So, in my original text this „in these cases“ has referred to the
> previous sentence. I think the additional sentences on DCCP that was added
> afterwards in the middle could be moved e.g. to the end of the paragraph.
>
>
>
> [MS] Yes, albeit the issue is actually related to internals of a router.
> The full paragraph talks about parallelism of packet processing inside the
> fast path of routers:
>
>
>
> [MS] As an admission control like Quick-Start has to change packet header
> fields according to available capacity, dynamically changing state
> information has to be kept consistent between the tasks/cores that forward
> IP packets in the router, in order to avoid inconsistencies and capacity
> overbooking. This runs into the typical issues of state synchronization in
> massively parallel systems and doesn’t scale well. Maybe a better wording
> would be: „One challenge is synchronization of information between
> different packets that are processed in parallel […]“
>
>
>
> Michael
>
>
>
>
>
> PS: I learnt myself a lot about the _*engineering*_ issues of path
> awareness when looking into actual routers and commercial network
> management software.
>