Subject: [Apn] APN Bandwidth, Jitter, Letency and Loss Requirements

From: Hesham ElBakoury <[email-masked]>
Date: Fri, 10 Dec 2021 10:15:09 -0800

Hi,

Are the latency, jitter, loss and bandwidth requirements specified for 
every packet or for the entire flow ? if it is for the entire flow then 
why these requirements are repeated in every packet of the flow.

Thanks

Hesham

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 13 Dec 2021 01:42:29 +0000

Hi Hesham, 

The intention was to carry these parameters to express the requirements of the traffic flow on the network, which could be used to steer the traffic into a specific path e.g. an SRv6 explicit TE path guaranteeing its latency. It could be only the first packet or set of packets. 

The usage scenario of carrying these parameters still needs more exploration. Do you have any thoughts or suggestions? The carrying of these parameters is optional as we specified in this draft https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#section-5. 

Thank you! 

Best regards, 
Shuping 

-----Original Message-----
From: Apn [mailto:[email-masked]] On Behalf Of Hesham ElBakoury
Sent: Saturday, December 11, 2021 2:15 AM
To: [email-masked]
Subject: [Apn] APN Bandwidth, Jitter, Letency and Loss Requirements

Hi,

Are the latency, jitter, loss and bandwidth requirements specified for every packet or for the entire flow ? if it is for the entire flow then why these requirements are repeated in every packet of the flow.

Thanks

Hesham

--
Apn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apn

---

From: Hesham ElBakoury <[email-masked]>
Date: Sun, 12 Dec 2021 18:14:03 -0800

Hi Shuping,
I think per packet latency and jitter make sense if you want the packet to
arrive at the destination by or on certain time. I am not sure if bandwidth
and loss should be specified per packet. These two parameters make more
sense when they are specified per flow.

You may need to add per packet drop precedence which describes different
levels of drop precedence based on congestion levels in the queues and
packet contents. These levels can be more granular than what can be
specified using DSCP or IEEE 802.1p.

I understand that bandwidth can be reserved per user, flows of a given
application but why you need to reserve bandwidth per packet ?

In IP datagram networks there is no guarantee anyway that packets of the
same flow will traverse the same route unless you use MPLS.  Why would one
wants to steer certain packets of the same flow to specific routes ? Is it
because the contents of these packets warrant special treatment that is
only available in the nodes of these specific routes ?

Thanks
Hesham

On Sun, Dec 12, 2021, 5:42 PM Pengshuping (Peng Shuping) <
[email-masked]> wrote:

> Hi Hesham,
>
> The intention was to carry these parameters to express the requirements of
> the traffic flow on the network, which could be used to steer the traffic
> into a specific path e.g. an SRv6 explicit TE path guaranteeing its
> latency. It could be only the first packet or set of packets.
>
> The usage scenario of carrying these parameters still needs more
> exploration. Do you have any thoughts or suggestions? The carrying of these
> parameters is optional as we specified in this draft
> https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#section-5.
>
> Thank you!
>
> Best regards,
> Shuping
>
>
> every packet or for the entire flow ? if it is for the entire flow then why
> these requirements are repeated in every packet of the flow.
>
> Thanks
>
> Hesham
>
> --
> Apn mailing list
> [email-masked]

---

From: John Grant <[email-masked]>
Date: Mon, 13 Dec 2021 18:01:56 +0000

On 13/12/2021 02:14, Hesham ElBakoury wrote:
> Hi Shuping,
> I think per packet latency and jitter make sense if you want the 
> packet to arrive at the destination by or on certain time. I am not 
> sure if bandwidth and loss should be specified per packet. These two 
> parameters make more sense when they are specified per flow.
Actually, I think it's latency and loss priority that make sense per 
packet. Jitter is the difference between latency for different packets, 
so only makes sense per flow.

>
> You may need to add per packet drop precedence which describes 
> different levels of drop precedence based on congestion levels in the 
> queues and packet contents. These levels can be more granular than 
> what can be specified using DSCP or IEEE 802.1p.
>
Quite.

>
> In IP datagram networks there is no guarantee anyway that packets of 
> the same flow will traverse the same route unless you use MPLS.  Why 
> would one wants to steer certain packets of the same flow to specific 
> routes ? Is it because the contents of these packets warrant special 
> treatment that is only available in the nodes of these specific routes ?
I guess if all packets of a flow go by the same route you can expect to 
get more consistent treatment, e.g. less jitter.

-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com
https://www.etsi.org/technologies/non-ip-networking

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 15 Dec 2021 11:48:37 +0000

Maybe we could try to classify these parameters into 2 groups: Statistics and Measured value. 
The statistics make sense per flow and measured value make sense per packet.
When the parameters belong to statics, it could be carried in the 1st packet of the flow when they are used to represent the requirements of the flow. 

Best
Xuesong

> From: Apn [mailto:[email-masked]] On Behalf Of John Grant
> Sent: Tuesday, December 14, 2021 2:02 AM
> To: [email-masked]
> Subject: Re: [Apn] APN Bandwidth, Jitter, Letency and Loss Requirements
> 
> Actually, I think it's latency and loss priority that make sense per packet. Jitter
> is the difference between latency for different packets, so only makes sense
> per flow.
> 
> >