[Sadcdn] Re: Éric Vyncke's No Objection on charter-ietf-scone-00-00: (with COMMENT)

[[e-mail]]

Hi Qin,

I’m lost here :-(

I understood from Markus reply that the advice is sent together with a flow **only for convenience**, but the advice is not specific to that flow and applies for other flows. I still see that as solution-specific, thought.

Your clarification binds the advice to a specific “end to end path”, which I find conflicting with the interpretation form Markus. I also don’t parse what “out of band” means here.

Not sure to get your comment about 3GPP.

Cheers,
Med

De : Qin Wu <bill.wu=[e-mail]>
Envoyé : jeudi 3 octobre 2024 16:09
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Eric Vyncke (evyncke) <[e-mail]>; Chris Box <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : [Sadcdn] Re: Éric Vyncke's No Objection on charter-ietf-scone-00-00: (with COMMENT)

Hi, Med:
Thanks for chiming in, my understanding to the first question, tying with 5 tuple is targeted to traffic going through end to end path,  it is in band, tying the advice with overall network access, which is edge to edge, covering only a subset of the end to end path, it is out band approach. I think these are two different approaches, both have different use cases, the charter focus on the former, i.e.,  improve user experience through interaction at the transport layer between endpoint and network device with application identification capability, shaper or policer functionalities.

The other two questions seem to me, more related to 3GPP developed admission control. I feel they deal with different use cases, focus on the phase before the connection is established. I haven’t thought them through, but Happy to discuss with you offline about these two questions. Thanks.

-Qin
发件人: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
发送时间: 2024年10月3日 14:19
收件人: Qin Wu <[e-mail]<mailto:[e-mail]>>; Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>; Chris Box <[e-mail]<mailto:[e-mail]>>
抄送: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: RE: [Sadcdn] Re: Éric Vyncke's No Objection on charter-ietf-scone-00-00: (with COMMENT)

Hi Qin,

Still the underlying questions are


  *   Why the advice has to be tight to a specific flow rather than the overall network attachment?
  *   Why and how a network will partition the overall resources among flows (read applications)?
  *   On which basis a network will determine that a subset of the overall capacity will be dedicated to a given flow?


Cheers,
Med

De : Qin Wu <bill.wu=[e-mail]<mailto:bill.wu=[e-mail]>>
Envoyé : jeudi 3 octobre 2024 13:41
À : Eric Vyncke (evyncke) <evyncke=[e-mail]<mailto:evyncke=[e-mail]>>; Chris Box <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : [Sadcdn] Re: Éric Vyncke's No Objection on charter-ietf-scone-00-00: (with COMMENT)

Hi, Eric:

发件人: Eric Vyncke (evyncke) [mailto:evyncke=[e-mail]]
发送时间: 2024年10月2日 23:02
收件人: Chris Box <[e-mail]<mailto:[e-mail]>>
抄送: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: [Sadcdn] Re: Éric Vyncke's No Objection on charter-ietf-scone-00-00: (with COMMENT)

Hello Chris,

Thank you for providing the two links to previous discussions, it seems that I touched the pain point.

As you know, my comment is just a comment, if the list has spent cycles on the issue and if the shepherding it agrees with the draft charter, then let it be.

BTW, I am curious to see how long it will take for some app developers to use different UDP 4-tuples by varying the source IP address/UDP port and bypass these known and announced limits.
[Qin] Interesting question, I think communicating network properties to clients is not unwanted traffic, if you as clients are not interested in this throughput advice, you will not receive it or simply ignore it. Note that the purpose of this information sharing is to help user experience improvement by adjusting bitrate. But not everybody can get such information. The operator will make such service available to users.
Just like you driving car in the high way, you have been told at the highway entry by toll attendant that you should limit your speed to 100km/h, if you don’t obey it, that is fine, but you will not get privilege to enjoy the benefit of advice told by toll attendant.


From: Chris Box <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 2 October 2024 at 19:19
To: Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Sadcdn] Éric Vyncke's No Objection on charter-ietf-scone-00-00: (with COMMENT)
On Wed, 2 Oct 2024 at 13:27, Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

s/a mechanism for network elements *capable of rate-limiting a* UDP 4-tuple/a
mechanism for network elements *enforcing a rate-limit for packets in a flow
identified by* a UDP 4-tuple/

Éric, you may not be aware that this particular wording was arrived at after a discussion [1] on this list. Your wording of "enforcing a rate-limit" is actually more restrictive than the one I was originally objecting to, which was "intending to rate-limit". For the reasons why I'm arguing for more open wording, see that message.

[1] https://mailarchive.ietf.org/arch/msg/sadcdn/eZLArJHdRYmrLXUDQl2X7_Y2wa8/

List participants also had issues with the word "flow", which is why it now doesn't appear in https://datatracker.ietf.org/doc/charter-ietf-scone/.

Of course the IESG are free to form their own view on charter wording; I just want to ensure you're aware of our input.

Chris

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.