Re: [spring] Mirja Kühlewind's Discuss on draft-ietf-spring-segment-routing-msdc-08: (with DISCUSS and COMMENT)

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

I'm not able to be on this week's discussion (in China, going back to bed
now), but if I support Mirja's Discuss on 7.1 and 7.2.

For what that's worth. Do the right thing, of course.

Spencer


On Thu, Jan 11, 2018 at 8:41 AM, Mirja Kühlewind <[e-mail]>
wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-spring-segment-routing-msdc-08: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Sorry for the late input, but based on the additional TSV review provided
> by
> Martin Stiemerling (Thanks!), I got convenienced that I would like to
> discuss
> the TCP related parts of this document further before publication (even
> though
> this is "only" an informational doc). I agree with the TSV review that the
> solution approaches discussed in 7.1 and 7.2 are slightly speculative and
> should therefore probably not be published in an RFC without further
> discussions in respective other groups of the IETF.
>
> Per-packet/flowlet path switching (7.1) will have an impact on the TCP
> machinery and should be further discussed in a tsv group before it would be
> presented as a solution approach in an RFC.
>
> Performance-aware routing (7.2) is actually a hard problem as congestion
> state
> is changing very dynamically and an attempt to utilize this information on
> a
> different time-scale than TCP does can lead to unwanted interfere and
> interdependencies. We currently have a proposed research group (PANRG) for
> this
> sort of problems, and this group would probably a better place for
> discussing
> these problems and proposed solutions (instead of an RFC-to-be).
>
> The easiest way to address my concerns is probably to removed TCP-related
> paragraph from section 3 as well as remove section 7.1 and 7.2 entirely and
> follow on those discussions in tsv area/tcpm and panrg instead.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have a question regarding this part in section 3:
> "The absence of path visibility leaves transport protocols, such as
>       TCP, with a "blackbox" view of the network.  Some TCP metrics,
>       such as SRTT, MSS, CWND and few others could be inferred and
>       cached based on past history, but those apply to destinations,
>       regardless of the path that has been chosen to get there.  Thus,
>       for instance, TCP is not capable of remembering "bad" paths, such
>       as those that exhibited poor performance in the past.  This means
>       that every new connection will be established obliviously (memory-
>       less) with regards to the paths chosen before, or chosen by other
>       nodes."
> Is that actually a well-known problem? This is not fully clear to me.
> Because
> given that usually all paths in a data center network have roughly the same
> characteristics (at least regarding the cached values such as SRTT and MSS)
> caching of TCP parameters should not be a problem in symmetric topologies
> like
> Clos. Or do you have any specific corner cases in mind?
>
>
>