Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3_DMLT] P802.3br IET, P802.1Qbu and 802.1Qbb PFC (was RE: Announcement - D1.00 Task Force Review: IEEE P802.3br IET)



(+Tony & 802.1)

 

Hmmm, interesting.

 

As an aside, taking one step back, TSN in general is addressing some of the same “no network drop” cases that PFC states it addresses (from 36.1.1 PFC Overview, “PFC enables to not discard frames due to congestion for protocols that require this property.”).

 

That being said, I assume that prior to IET, PFC messages (as a M_CONTROL.request) are considered for transmission as “more important” than anything in the normal queueing/transmission selection process, and so the worst case delay in sending a message is an MTU work of transmission time.

 

I agree that we need to figure this out, and I’m wondering if this problem is only relevant to PFC, or are there other “control messages” that have expectation for only have an MTU’s work of delay time.

 

If we say that PFC uses the express MAC, then I think that makes the network scheduling very complex because you have to estimate how many PFCs need to be sent. I’m not a PFC expert, but what does it say about the max rate/min time between PFC messages? If we can push PFC though the express channel, it probably improves PFC performance at the cost of scheduled express traffic.

 

Regards

Peter

 

_______________________________________________

Peter Jones             Cisco Systems

Principal Engineer      3600 Cisco Way

ENG Switching Software  San Jose, CA, 95134 USA

Tel: +1 408 525 6952    Fax: +1 408 527 4698

Email:                  petejone at cisco.com

Twitter:                @petergjones

_______________________________________________

 

From: Beaudoin, Denis [mailto:dbeaudoin@xxxxxx]
Sent: Thursday, December 11, 2014 10:46 AM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DMLT] Announcement - D1.00 Task Force Review: IEEE P802.3br IET

 

The only concern for PFC frames on the non preempted path is that it now increases the receiver run out by the maximum preempted frame since a preempted frame can now delay the PFC frame, this delay allows the remote to send more regular traffic. It is even worse if a single max frame is preempted multiple times before the PFC frame is sent. My coworker pointed out that since a preempted frame can be preempted multiple times and each preemption could be a burst of preempted frames, than the run out was not fixed and could be huge! If the PFC frame was on the preempted channel, the preempted traffic would only be delayed by max of 84 byte times.

 

Regards

Denis Beaudoin  DMTS  Texas Instruments  dbeaudoin@xxxxxx W: 214-480-3287/77  M: 214-475-9193

 

From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]
Sent: Thursday, December 11, 2014 12:33 PM
To: Beaudoin, Denis; STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: RE: Announcement - D1.00 Task Force Review: IEEE P802.3br IET

 

I recall any discussion in the task group of that and I’m not sure there is a uniform answer.

 

My own view, there will be a lot of cases where PFC and express traffic are not used at the same time. (I’d prefer to use express to describe the traffic on the path that can preempt – TSN is a broader term that includes uses of scheduled traffic or the credit based shaper without preemption.)

 

If they are both being used, in the most time sensitive use cases (e.g. we created the hold primitive because some found the possible 139 octet worst case delay before preempting too long) , one wouldn’t want sending a PFC to delay sending a scheduled frame.

 

On the other hand, in less extreme time sensitive use cases, it may be desirable to put PFC frames on the express path.

 

Something to discuss in January.

 

Regards,

Pat

 

From: Beaudoin, Denis [mailto:dbeaudoin@xxxxxx]
Sent: Thursday, December 11, 2014 6:25 AM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DMLT] Announcement - D1.00 Task Force Review: IEEE P802.3br IET

 

Typo…

 

Regards

Denis Beaudoin  DMTS  Texas Instruments  dbeaudoin@xxxxxx W: 214-480-3287/77  M: 214-475-9193

 

From: Beaudoin, Denis
Sent: Thursday, December 11, 2014 8:15 AM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DMLT] Announcement - D1.00 Task Force Review: IEEE P802.3br IET

 

Ludwig, looking at the IET did we decide where 802.1Qbb pause frames are sent?

That is are pause frames considered TSN frames or non-TSN frames?

 

The reason I ask is that if pause frames are TSN frames, then Rx run out could be smaller than today, but assuming that TSN may not be supported by the link partner than what is required today is a minimum.

But if pause frames are non-TSN frames, then the pause run out is increased by the largest TSN frame plus IPGs times two plus some slop! If TSN frames can be 2000bytes, then this increases the Rx runnout requirements by 4000+ bytes.

 

Regards

Denis Beaudoin  DMTS  Texas Instruments  dbeaudoin@xxxxxx W: 214-480-3287/77  M: 214-475-9193

 

From: Winkel, Ludwig [mailto:ludwig.winkel@xxxxxxxxxxx]
Sent: Thursday, November 27, 2014 4:00 AM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: [802.3_DMLT] Announcement - D1.00 Task Force Review: IEEE P802.3br IET

 

Dear Colleagues:

 

This is the announcement of the review of the IEEE P802.3r Interspersing Express Traffic (IET) Task Force (TF) draft amendment D1.0.  Instructions for accessing the draft and submitting comments follow this announcement.

 

IEEE P802.3br is an amendment to IEEE Std 802.3-2012 which is available through the “Get 802” program at the URL:

http://standards.ieee.org/getieee802/802.3.html

 

The Project Authorization Request for this amendment is posted at:

http://www.ieee802.org/3/br/P802d3br_PAR.pdf

 

The Five Criteria Responses for this amendment are posted at:

http://www.ieee802.org/3/br/8023-DMLT-SG-1311-Winkel-5C-v2.3.pdf

 

The Objectives for this amendment are posted at:

http://www.ieee802.org/3/br/8023-DMLT-SG-1309-Winkel-Objectives-v2.3.pdf

 

Other related documents are posted at:

http://www.ieee802.org/3/br/index.html

 

___________________________________________

 

REVIEW SCOPE:

The scope of the review is the entire IEEE P802.3br D1.0 Draft.

 

REVIEW OPEN:

Thursday, 27th, November 2014

REVIEW CLOSE:

Monday, 1st, January 2015 11:59pm AoE

 

-------------------------------------------------------------------------

HOW TO ACCESS THE DRAFT

The draft is posted for Task Force review purposes only, and neither the draft nor access information should be copied or redistributed to others in violation of document copyrights.

 

Draft 1.0 should be used for commenting and may be downloaded from:

URL: http://grouper.ieee.org/groups/802/3/br/private/01_TF_Drafts/P8023br-D1.00p0.pdf

Username and password: distributed at meetings

 

The document is posted in Adobe "pdf" document format and can be downloaded and printed if desired. If you do not have Adobe Acrobat Reader, it is available for free downloading from Adobe at:

URL: http://www.adobe.com/prodindex/acrobat/readstep.html

 

_______________________________________

HOW TO SUBMIT COMMENTS

 

Acceptable comment types:

 

E = Editorial

ER = Editorial Required (an Editorial comment that the commenter feels very strongly about) T = Technical TR = Technical Required (a Technical comment that the commenter feels very strongly about)

 

For further information regarding comments, please see http://www.ieee802.org/3/bj/public/may12/diab_01_0512.pdf

 

1. Prepare your comments in one of the following two ways:

 

a. You are STRONGLY REQUESTED to use the comment tool in the TF private area at the URL:

 

URL: http://ieee802.org/3/WG_tools/filemaker/index.html

Please download and read the Comment Tool Tutorial:

http://www.ieee802.org/3/bj/public/may12/diab_01_0512.pdf

 

To use the tool, extract all components into a folder and do not move any component from that folder as this will cause the executable to not work correctly. The tool is:

 

Comment_Tool_Generic_Solution.exe

 

The comment tool runs under Microsoft Windows. It has also been run in VM environments on other platforms.

 

b. To submit comments in text (ASCII) form, please use the form below.  This will make it possible for the editor to properly record and track all submissions. Make as many copies of the template as necessary and submit as an ASCII text file or as part of your e-mail.

 

PLEASE NOTE: The ASCII method involves a manual transcription, hence you are recommended to check your comments to ensure accurate transcription when the comment file is made available. Please use the comment tool above if possible.

 

------CUT AND PASTE TEXT BELOW THIS LINE ONLY PLEASE--------

 

CommentID: (Leave Blank)

CommenterName:

CommenterEmail:

CommenterPhone:

CommenterCellPhone:

CommenterCompany:

Clause:

Subclause:

Page:

Line:

CommentType: (E, ER, T, or TR)

Comment:

CommentEnd:

SuggestedRemedy:

RemedyEnd:

 

--------------------end comment template------------------

 

2. Send your comments to: pthaler@xxxxxxxxxxxx, CC Ludwig.Winkel@xxxxxxxxxxx , mike@xxxxxxxxxxxxxxx and paste into the subject line:

 

IEEE P802.3br IET Task Force D1.0 comments

 

_____________________________________________________________

 

Thank you for your participation in this review and careful review of the draft.

 

Pat Thaler, Broadcom

Editor, IEEE P802.3br Task Force

 

 

Ludwig Winkel, Siemens

Chair, IEEE P802.3br interspersing Express Traffic Task Force http://www.ieee802.org/3/br/index.html

 

 

 

Mit freundlichen Gruessen / With best regards,
Ludwig Winkel


  Vice-chair of IEEE P2413

   Chair of the IEEE P802.3br Task Force

   Vice-chair of IEC SG8

   Convenor of IEC SC65B/WG16

   Convenor of IEC SC65C/WG17

   Convenor of IEC SC65C/MT9

   Convenor of CENELEC TC65X/WG1

 

Mail: Siemens AG , PD TI FC
        Oestliche Rheinbrueckenstr. 50
        76187 Karlsruhe, Germany
Tel.: +49 721 595-6098
Mobile: +49 172 6132658
mailto:ludwig.winkel@xxxxxxxxxxx

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Hermann Requardt, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322