RAW WG - Interim 03 - Architecture

Date: Friday July 15, 2022
Time: 8:00 PT | 15:00 UTC | 17:00 Paris - 60 mins
Chairs:
Rick Taylor rick@tropicalstormsoftware.com
Eve Schooler eve.m.schooler@intel.com
Responsible AD: John Scudder jgs@juniper.net

Pascal = Pascal Thubert
John = John Scudder

Pascal - discussing the need for transport support for RAW/DETNET.
Problems with running TCP over DETNET - doesn't work - window growth
results in packet drops
Carsten Bormann (chat) - TCP over DETNET doesn't work
Pascal - Draft on proposed transport protocol exists (old)... Pull...
John: Isn't it sufficient to know the rate?
Pascal: There is also timing
Make sure the host is synchronized to the switch

Rick: charter, PAREO, ... control plane to establish, way of doing this;
layers below the data layer (IEEE TSN, ETSI 5G, ...) link layer
solutions that DETNET binds together. RAW WG is about a path including
wireless link.

Carsten: The architecture has to say what assumptions it makes about
things that are out of scope of the architecture.

Pascal: Assumption that DETNET runs e2e

Rick: DETNET use cases; Pro AV packetized over UDP, Utility grids,
packetized data (https://datatracker.ietf.org/doc/rfc8578/)

Pascal: DETNET needs a UNI interface; not specified.

Rick: Should there be a TSV BOF about a "DTP/IP", deterministic
transport protocol

Lou: great topic, transport issue; nothing specific to RAW, general
DETNET problem; having the transport protocol be aware about what is
below it; protocols for measuring and self-adjusting; TCP or maybe
better RTP

Rick: reactive/discovering vs. non-reactive -- told at establishment
that certain path characteristics are available

Lou: Yes, except that we don't need a new transport protocol; CC
algorithm could be informed by lower layer information

Pascal: transport needs to know that it is time to send the next thing;

Lou: Pause, credit-based... classic

Pascal: ...shaper...

Lou: do we need a new protocol? Prefer to solve it with existing
transport protocols; applications are tied to them (Rick: and
middleboxes)

Rick: can this be pushed back into QUIC?

John: respond to q earlier: should we try to capture in the document?
Carsten's point: if the arch needs certain attributes from the lower
layers to be useful ; if it is important probably you should write that
down!

Rick: +1

Lou: rather than in the RAW arch, make it its own document and make it a
DETNET document

Pascal, Rick: A short statement needs to be in there, even if it is in
more detail elsewhere

Rick: resurrect Pascals TSV document?

Lou: right place is in TSVWG

Rick: creating a new transport protocol -> TSV, but a problem statement
"if you are using DETNET, you have these issues to look at"

Lou: DETNET requirements document should come out of DETNET; solution
document would not be right there.

(The doc in question:
https://datatracker.ietf.org/doc/draft-thubert-tsvwg-detnet-transport/)

ACTIONS:
1) Pascal to send the doc to the DETNET list to raise awareness. RAW
chairs to support in person at DETNET WG meeting.
2) Pascal to add a few sentences highlighting upper-layer
considerations.