Re: [RPRWG] More comments on preemption
Dear Ajay:
MAC just allows for maximum packet size, it has usually nothing to do with what size
L3 sessions have set up for their information exchange. Therefore there are no
control procedures for MTU discovery or establishment.
Here is what my take on jumbo packets: for networks where there are lot of SAN-type
data (sorry to keep bringing SAN, but that is one application that I can readily
think of that will definitely benefit from use of large size packets) nodes will
negotiate for large MTU sizes. Users will be prudent to not demand real-time services
for small packets on those networks. On others where real-time or near real-time
services are being run users typically will not be looking for huge packet sizes.
Since networks are almost always segmented through interconnecting nodes, this isn't
a problem.
All the RPR MAC does is to 'allow' for the maximum MTU size.
This allows RPR MAC to be really pervasive - not coming in the way of applications &
networks, and be truly usable regardless of application.
This is why I feel we shouldn't unnecessarily worry about whether or not to preempt
packets. Preempting packets will make MAC complex, without much positive benefits.
Leave it to applications. If applications require smaller packets to achieve
something, they will send small packets (fragmentation, small IP size, etc.) and MAC
wouldn't even know of this happening.
Regards,
Pankaj
Ajay Sahai wrote:
> Hi Pankaj
>
> If RPR allows for MTU negotiation I have no issue with Jumbo Frames. However
> I have not seen any control protocols that do such functions for RPR.
>
> Pankaj K Jha wrote:
>
> > And, if any network cannot tolerate larger MTU sizes,
> > nodes can always negotiate lower MTU - this is fairly standard.
> >
>
> Is there any interest in the group to invent/adopt/extend any protocols that
> do these functions? If not I would like to understand how these functions will be
> done.
>
> Thanks
>
> Ajay