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 <[email protected]> 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? > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
