Subject: Re: [PANRG] [arch-d] IAB Adoption of draft-arkko-iab-path-signals-collaboration-01

From: "Luis M. Contreras" <[email-masked]>
Date: Mon, 27 Dec 2021 19:04:58 +0100

Hi all,

I have gone through this draft and I have some comments that I would like
to share:

.- The second paragraph on Introduction comments on the fact that various
fields of TCP can be used to derive information and that way of
proceeding is easier and cheaper than any explicit approach. I think this
statement is not correct in the sense that deriving information implies
some processing and inferring of information that does not exist in an
explicit method where direct information communication can avoid any bad
interpretation or inference. Same applies to complexity. For me it is much
more complex to derive behaviors from indirect information than for direct,
cooperative one (where all the information follows some standard without
any possibility of wrong interpretation). I suggest removing that sentence
or to reformulate just the other way around.

- When referring to the network, the draft refers basically to path
elements, which can be interpreted as network nodes. I assume that control
elements or management systems could be also part of the elements
considered in the draft, but it would be probably good to make an explicit
statement in this respect, so making clear that either network nodes or
control/management systems can be part of the interaction with senders are
receivers.

- In the paragraph just before sub-section 3.1 it is mentioned the term
"path function". It is not clear to me the meaning of that term in the
context of the draft.

- The 4th paragraph in section 3.4 states "It may also have undesirable
economic consequences, such as extra charges for the consumer from a
priority service where a regular service would have worked." In this
particular case, what is the rationale for the application in using some
priority? I think that the intended collaboration can precisely promote
incentives to save scarce resources, especially in critical situations (see
for instance RFC9075).

- Last sentence of section 3.5 states that "our recommendation is to employ
very targeted, minimal information carriage mechanisms". Linked with my
comment before, for control/management systems (controlling the network
nodes) such minimal information could be easily defined by means of APIs in
the interaction with senders and receivers. So adding an explicit mention
to this as further work can help to develop such collaborative ways of
interaction.

- Further work section, in its last bullet, makes an explicit reference to
"Sharing information from networks to applications' '. In my opinion also
an statement in the sense of "Sharing information from applications to
network" should be also added, since having both mechanisms can be
beneficial to the overall purpose of collaboration for improving service
expectation.

Thanks

Best regards

Luis

El mié, 10 nov 2021 a las 18:10, IAB Executive Administrative Manager (<
[email-masked]>) escribió:

> The IAB will discuss adoption of
> draft-arkko-iab-path-signals-collaboration-01 (Considerations on
> Application - Network Collaboration Using Path Signals) on the IAB stream
> at its meeting on 2021-11-17.
>
> The draft can be found here:
> https://datatracker.ietf.org/doc/draft-arkko-iab-path-signals-collaboration/
>
> The agenda for the meeting will be posted 48 hours ahead of the meeting
> here: https://www.iab.org/wiki/index.php/Agenda
>
> Feedback about this draft can be sent in response to this mail on
> [email-masked], or to the IAB directly at [email-masked].
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica