Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS)
On 09/12/2013 10:39 PM, Sam Hartman wrote: 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. Ok, I see. I will clear. Thanks, Martin ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS)
On 9/30/13 3:46 AM, Martin Stiemerling wrote: On 09/12/2013 10:39 PM, Sam Hartman wrote: 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. Ok, I see. I will clear. Thanks! spt ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS)
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
Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS)
Hi Joe, Sorry for the delayed response -- I have been away for my vacation. On 08/10/2013 01:20 AM, Joseph Salowey (jsalowey) wrote: On Aug 8, 2013, at 12:24 PM, Martin Stiemerling martin.stiemerl...@neclab.eu wrote: Martin Stiemerling has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-07: Discuss -- DISCUSS: -- Two points about Section 3.7. Fragmentation - Both ends have to wait for either each fragment or fragment ack to arrive. However, the timers on how to long to wait before giving up waiting for fragments or acks are missing. [Joe] Retransmission and timeout behavior for EAP is discussed in the EAP RFC 3748 Section 4.3. The cited section describes retransmission and the associated timeouts for complete messages, but **not** fragments! RFC 3748 says clearly in Section 1: Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. I assume TEAP is an EAP method that has to write-up how fragmentation is handled, isn't it? - how does the sending TEAP entity determine what the maximum transmission unit (MTU) of the path is? [Joe] Typically EAP receives MTU information from the lower layer. This is described in EAP RFC 3748 section 3.1. Ok, I am fine to clear this position if you add a pointer to RFC 3748, Section 3.1 -- as a reminder for the implementers where to look for guidance. Martin -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS)
Hi Sam, 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. It is not about the EAP timeouts for whole messages, but timeouts for fragments are not defined in RFC 3748 and must be defined somewhere, as well as, what happens if timeouts are exceeded for fragments. Martin -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
