Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

> Each node can use its local clock to count the budget that has been used
and pass the remaining  budget to the next hop.

Last time I looked at router architecture the most time was spent on egress
queuing. So you want to modify the packet header post egress LC queueing
??? Original !

> transmission delay can’t be counted but that is constant for a link so it
can be discounted in advance.

Seriously ?  Link transmission is constant ? Today say you are enterprise.
In global WAN vast majority of links are emulated circuits over some elses
IP network. The delay of traversing such links varies often orders of
magnitude depending how underlay carries the packets or even how it hashes
the packets.

And such link delays is what makes applications unhappy, not really
router's switching delay if you watch your network and never get to 60%-80%
peak utilization of any egress interface.

While I do have sympathy to drop junk as early as we know it is junk I am
worried about application reaction on such drops as well the decision
leading to determine that it is junk.

Interesting ....

Cheers,
R.

On Thu, 28 Apr 2022 at 23:10, Haoyu Song <[e-mail]> wrote:

> [TS3]: Yet for other applications (like delay budgeted ones), the delay
> budget is for each path (and for each segment or transit hop on that path).
> Signaling such delay budget on that path will make it a per path state.
>
>
>
> As noted this is an unrealistic use case. Unless you illustrate how to
> synchronize time in WAN to   the 10s of ns precision I am not going to
> spend any time on such a use case.
>
>
>
> Besides you are going to waist much more precious forwarding time to
> analyze such budget at selected LSR then if budget is not met blindly and
> randomly drop packet ? If packets come too late receiving application can
> drop it. Putting burden to do such filtering into the IP/MPLS network is a
> truly terrifying idea (to say it lightly :)).
>
>
>
>
>
> *I actually don’t think this is a terrifying idea. **😊** If a packet is
> set to miss its delay target, it makes no sense to continue forwarding it
> because that will waste network bandwidth and processing power for both
> routers and end hosts. *
>
> *Also, there is no need for network-wide synchronization for this use
> case. Each node can use its local clock to count the budget that has been
> used and pass the remaining  budget to the next hop. Of course, this way
> the transmission delay can’t be counted but that is constant for a link so
> it can be discounted in advance.  *
>
> *If we design also for possible innovations in future, we can’t ignore
> such use cases.  *
>
>
>
> *Best regard,*
>
> *Haoyu*
>
>
>