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

[Mirja Kühlewind <[e-mail]>]

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?