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

[Spencer Dawkins at IETF <[e-mail]>]

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 <
[e-mail]> wrote:

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