RE: Frame-Relay Fragmentation at Interface Level

From: Vincent Mashburn (vmashburn@fedex.com)
Date: Wed May 31 2006 - 10:09:25 ART


I think what is going on here is that the IOS partitions memory for
another software queue for delay sensitive traffic. I can't see a
special FIFO queue just sitting there unused until fragmentation is
configured. It has always been my understanding from everything that I
have read that there is only one hardware queue per interface. In the
special case of sub-interfaces, the IOS and the configuration that the
administrator supplies decides how the traffic from the sub-interfaces
shared the tx-ring for the hardware queue.

Vince Mashburn
Voice / Data Engineer
901-263-5072
CCVP, CCNP, CCDA,Network +
Cisco IP Telephony Support Specialist
Cisco IP Telephony Operations Specialist
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Petr Lapukhov
Sent: Wednesday, May 31, 2006 12:36 AM
To: Schulz, Dave
Cc: Cisco certification
Subject: Re: Frame-Relay Fragmentation at Interface Level

Sure Dave,

That's what's puzzling me :) That's not a major topic for R/S,
so don't think of that as a serious issue. But actually, that's a matter
of deep understanding :)

Digging through DocCD last night, I finally came up to some conclusions.

Looking at MLPPP Interleave, I found the same idea:

--- quote

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fdial
_c/fnsprt9/dcdppp.htm#wp1001860

The interleaving feature also provides a special transmit queue for the
smaller, delay-sensitive packets, enabling them to be sent earlier than
other flows.

--- quote

Well, that queue is hard to observe, but it shows up with "show int".
Okay,
now
that's how interleaving works here, with MLPPP.

So there also must be some sort of "hidden" (additional) dual FIFO
"between"
software queue and TX-Ring for Frame Relay Interface with FRF.12
configured
on
interface. Maybe I should drop a letter to W. Odom and ask him directly
what's
going on here:)

Finalizing the case:

1) With Legacy FRTS + FRF.12 we have per-VC queues (shapers' queue)
and
per-Interface Dual FIFO to do interleaving. Data Flow seems to be that
that:

[Per-VC queue(WFQ/CQ/PQ/CBWFQ/LLQ)]->[Compression(RTP/Payload)]->
->[Fragmentation]->[Dual FIFO(Inteleaving at Interface Level)]->[TX
Ring]

Fragmentation decision and Classification for Dual FIFO is based solely
on
packet
size, so we may freely shrink and compress packets here.

2) With FRF.12 and Queueing at Interface level: Interface queue may be
of
any
type (it's not hardwired to Dual FIFO). One may also put shapers at
sub-interfaces
for his/her pleasure. Another one may configure MQC at interface :)

But basically data flow seems to be that:

[Inteface Queue (WFQ/PQ/CQ/CBWFQ/LLQ)]->[Compression]
->[Fragmentation]->[Hidden Dual FIFO (Interleaving)]->[TX Ring]

Petr

2006/5/30, Schulz, Dave <DSchulz@dpsciences.com>:
>
> Petr  On your first statement about doing the interleaving at the
> hardware queue level. I may have this wrong, but I thought that you
cannot
> do any fragmentation, classification or whatever AFTER the packet has
gone
> to the Tx-Ring. Any clarification is appreciated.
>
>
>
>
>
> Dave Schulz,
>
> Email: dschulz@dpsciences.com <dschulz@dpsciences.com%20>
>
>
> ------------------------------
>
> *From:* Petr Lapukhov [mailto:petrsoft@gmail.com]
> *Sent:* Tuesday, May 30, 2006 2:29 PM
> *To:* Schulz, Dave
> *Cc:* Cisco certification
> *Subject:* Re: Frame-Relay Fragmentation at Interface Level
>
>
>
> Dave,
>
> hardware queue is always FIFO, no matter what. Now the real problem
> is to interleave the small packets and fragments of large ones in that
> queue.
>
> FRTS does that by the virtue of Dual FIFO at interface level. That
is,
> this priority queue is used to do LFI. Fragmentation is peformed
before
> Dual FIFO, small packets go high, fragments go low, and then
interleaving
> takes place.
>
> So the question is how that thing could be done without Dual FIFO :)
> It seems to work somehow with fragmentation at interface level.
>
> Petr
>
> 2006/5/30, Schulz, Dave <DSchulz@dpsciences.com>:
>
> Great subject for discussion, Petr! I believe that the order of
> operation needs to be classification, before fragmentation. And, any
> scheduling or queueing (FIFO) needs to be done at the software level.
> Please someone correct me if I am wrong, but the hardware queue
> (TX-Ring) will only do FIFO once any packets are in that queue....you
> cannot (or, would not want to) manipulate them. HTH.
>
>
> Dave Schulz,
> Email: dschulz@dpsciences.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Petr Lapukhov
> Sent: Tuesday, May 30, 2006 1:00 PM
> To: Cisco certification
> Subject: Frame-Relay Fragmentation at Interface Level
>
> Hello group,
>
> The question I have may sound boring, but I think it would be really
> useful
> to investigate
> that matter :))) Not to mention that it touches some deep QoS topics.
>
> To start with, let's recall FRF.12 with FRTS legacy. The main idea is
to
> enable fragmentation AND
> interleaving. Interleaving is performed by the Dual FIFO queue at
> interface
> level, where "small"
> packets go to high priority queue, and "large", fragmented packets are
> directed to low priority queue.
> This is the way how interleaving works in that case. Small packets get
> BETWEEN fragments of large
> ones.
>
> An important thing to remember, is that packets are *first* dequeued
> from
> *PVC-level* queue
> (which is WFQ by default, when FRF.12 is turned on). Next, packets are
> compressed, and then
> fragmented. Therefore, fragmentation occurs AFTER per-VC dequeueing.
>
> Note, that fragmentation decision is based solely on *packet size*,
you
> voice (small) packets may
> be fragmented as well :)
>
> Now, we have that new FRF.12 at interface level (12.2(13)T):
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hw
> an_c/ch05/hfrfrint.htm
>
> What's happening here? As far as I get it, fragmentation should occur
> AFTER
> interface level queue is
> processed, and packets are compressed (payload/RTP). The question is -
> how
> does INTERLEAVING
> happen in that case? There is NO Dual FIFO that may help here (At
least
> I
> did not find it with show
> commands :))
>
> DocCD vaguely mentions that interleaving happens only when LLQ is
> configured
> at interface level.
> But that means packets should be enqueued AFTER fragmentation? Is that
> possible to classify
> fragmented data?
>
> This is my doubt. Investigating a bit, I found, reading W. Odom's
"CCIE
> R&S
> Certification Guide
> 2006" that Dual FIFO still exist "between" software and hardware
queue.
> But
> how could one verify
> that? :)
>
> Hope I don't not bother you too much :)
>
> Petr
>
>



This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:23 ART