| Re: Proposed Resolution of Issue 188: Packet ordering | <– Date –> <– Thread –> |
|
From: Lauri Tarkkala (ltarkkal |
|
| Date: Wed, 29 Oct 2003 09:08:45 -0600 (CST) | |
On Mon, Oct 27, 2003 at 07:18:20PM -0800, Bernard Aboba wrote: > Issue 188: Packet Ordering > Submitter name: Margaret Wasserman > Submitter email address: Margaret.Wasserman [at] nokia.com > Date first submitted: October 23, 2003 > Reference: > Document: RFC 2284bis-06 > Comment type: T > Priority: S > Section: 2.3 > Rationale/Explanation of issue: > > Is the current wording/diagram in the document clear > enough with respect to the need for IP-based > transports to include a mechanism to ensure packet order? > Or do you think that we should add a couple of sentences > to make this more explicit and explain what "/IP" means > in Figure 2? Am I missing something here, but the bis specification is currently stating that EAP is a lock-step protocol. In this case, assuming nobody is doing optimizations based on predicting peer responses, there should be no need for an ordering guarantee. That said, requiring that the lower layer provides an ordering guarantee is a good idea considering the heritage of EAP. I do not however see this as much of an issue for new (or upto-date) implementations, which we would be talking about here. Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/
-
Proposed Resolution of Issue 188: Packet ordering Bernard Aboba, October 27 2003
- Re: Proposed Resolution of Issue 188: Packet ordering Jari Arkko, October 28 2003
- Re: Proposed Resolution of Issue 188: Packet ordering Lauri Tarkkala, October 29 2003
-
RE: Proposed Resolution of Issue 188: Packet ordering Pasi.Eronen, October 29 2003
-
Re: Proposed Resolution of Issue 188: Packet ordering Lauri Tarkkala, October 29 2003
- Re: Proposed Resolution of Issue 188: Packet ordering Jari Arkko, October 29 2003
-
Re: Proposed Resolution of Issue 188: Packet ordering Lauri Tarkkala, October 29 2003
Results generated by Tiger Technologies using MHonArc.