To get some of the required behaviors may involve the operator
supporting/configuring features in their network that allow a transport
to function within the necessary performance envelope.
For instance, the operator may need to configure:
- AQM
- ECN
- L4S
- DiffServ PHBs
- etc.
On 3/27/2024 10:59 AM, Renan Krishna wrote:
Hi Wesley,
Many Thanks for your review. Although, the issue of what transport or other protocols need to do is important, we feel that it is out of scope of our document. Our document is intended for "network operators who are interested in providing edge computing resources to operationalize the requirements of such applications". At the time the application is being operationalized by a network operator, the decision of what happens at the transport layer has already been made by for example the application developer. So, we have omitted any discussion of such issues in our draft.
Regards,
Renan
-----Original Message-----
From: Wesley Eddy via Datatracker <noreply@xxxxxxxx>
Sent: Tuesday, March 26, 2024 3:17 AM
To: tsv-art@xxxxxxxx
Cc: draft-ietf-mops-ar-use-case.all@xxxxxxxx; last-call@xxxxxxxx; mops@xxxxxxxx
Subject: Tsvart last call review of draft-ietf-mops-ar-use-case-15
Reviewer: Wesley Eddy
Review result: Ready with Issues
This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.
When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review.
The document reads well and is easy to understand. It is a nice overview of the use case that it describes, and does a great job explaining terminology and providing relevant resources.
My only issue with the present revision, is that in reviewing from a TSVART perspective, I see that there is discussion of latency and bandwidth needs, but there does not seem to be much discussion of what the transport or other protocols need to do to facilitate the use case. For instance, are there multiple independent streams (for audio, video, and data), and how many, that would make use of either multiple independent transport connections (with their own congestion control), or multiple streams within a QUIC or SCTP association?
Would an unreliable datagram service be preferable to a retransmission-based / reliable service for some or all of the streams? Would FEC be useful? The rates discussed are very high; are there congestion control needs e.g. fast startup, smooth/scalable responses, coupling with ABR, etc. that need to be explored?
[Banner]
[Banner]<http://www.interdigital.com/white_papers/defining-the-xr-experience-enabling-the-immersivity-ecosystem-?utm_source=signature&utm_medium=Email&utm_term=xr&utm_content=banner&utm_campaign=defining_the_xr_experience>
Defining the XR Experience: Enabling the Immersivity Ecosystem<http://www.interdigital.com/white_papers/defining-the-xr-experience-enabling-the-immersivity-ecosystem-?utm_source=signature&utm_medium=Email&utm_term=xr&utm_content=banner&utm_campaign=defining_the_xr_experience>
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
