>>>>> "Martin" == Martin Stiemerling <mls.i...@gmail.com> writes:
Martin> Sam,
Martin> On 08/24/2013 03:41 PM, Sam Hartman wrote:
>>>>>>> "Martin" == Martin Stiemerling
>>>>>>> <martin.stiemerl...@neclab.eu> writes:
>>
Martin> Hi Sam,
Martin> On 08/14/2013 10:16 PM, Sam Hartman wrote:
>> >>>>>>> "Joseph" == Joseph Salowey (jsalowey)
>> <jsalo...@cisco.com> >>>>>>> writes:
>> >>
Joseph> [Joe] Retransmission and timeout behavior for EAP is
Joseph> discussed in the EAP RFC 3748 Section 4.3.
>> >>
>> >> Echoing Joe's point, we over in abfab
>> (draft-ietf-abfab-gss-eap) >> would be really unhappy if EAP
>> method specs started discussing >> timeouts.
>>
Martin> It is not about the EAP timeouts for whole messages, but
Martin> timeouts for fragments are not defined in RFC 3748 and must
Martin> be defined somewhere, as well as, what happens if timeouts
Martin> are exceeded for fragments.
>>
>> If an inner method supports fragmentation, then each fragment is
>> a "whole EAP message," in your terminology quoting RFC 3748.
Martin> So, for the unexperienced EAP people like me, TEAP is the
Martin> inner method? TEAP is running within EAP.
*sigh*
I'm sorry, I used the wrong terminology.
Inner method doesn't come up here; that would be a case where say you
were running EAP-AKA inside TEAP.
Rephrasing to apply to your situation.
If an EAP method supports fragmentation, that fragmentation is handled
by the method. That is both fragmented and un-fragmented messages
within the view of the method are "whole messages," as considered by
EAP.
We see a similar situation with IP and ethernet. Ethernet (at least the
version I learned about back when ethernet was simple) doesn't support
fragmentation. Each IP datagram, whether it's a fragment or not, is a
whole ethernet frame.
As it happens, ethernet doesn't provide end-to-end service, and for a
bunch of other reasons tdhat don't apply to EAP, you need to talk about
retransmission at the IP layer as well as to some extent at the ethernet
layer.
However, with EAP, the EAP layer provides a reliable end-to-end service
and entirely takes on the retransmission task (unless EAP itself is
running over a lower layer that takes on retransmission and sets the EAP
retransmit timeout to infinite).
A method can fragment, but unlike IP, the fragmentation mechanism is
entirely disjoint from retransmission.
There are probably inefficiencies here because of that disconnect.
however, EAP is not trying to be an efficient transport. And handling
retransmission on the EAP side of the boundary and fragmentation on the
method side side of the abstraction boundary provides valuable benefits
for EAP. Like the state machine between the method and EAP can be
lock-step without the method ever triggering an event. That's quite
important for the way people have grown to build EAP software.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
