Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document

From: Ross Finlayson <[email-masked]>
Date: Wed, 7 Dec 2016 13:30:36 +1300

> This is a call to adopt draft-wei-payload-has-over-rtp-01 as a Payload WG document and create a milestone for this 
> 
> There was already support to adopt it in  the payload session at IETF97

That’s not quite the impression I got.  At the Payload session in Seoul (and also in Berlin), there seemed to be quite a bit of scepticism - in particular, about whether RTP is the right protocol for them to be using (for multicast delivery of video segments).

The basic problem is that, right now, the proposed payload format makes little real use of the features of RTP - basically, the only part of the RTP header that is used in any meaningful fashion is the RTP sequence number (for identifying and reordering out-of-order network packets).  However, in order to be used effectively (on multicast networks with non-negligible packet loss), video segments will need to be delivered reliably (i.e., in their entirety).  There *are* mechanisms available within the overall RTP architecture that could help provide reliable delivery - e.g., Flexible FEC; the RTP/AVPF profile - but these are not mandated (or even mentioned, except very briefly in section 6.1) in the current Internet Draft.

>  and this email is to verify the support
>  
> Please provide any view to the list by December 7th

In short: I'd support adopting this as a WG document *only if* the authors:
	1/ Better justify their choice of RTP as the transport protocol for multicast delivery of video segments, and
	2/ Describe specifically how they’re going to achieve *reliable* multicast delivery of video segments (or else note explicitly that their approach is intended only for multicast networks in which packet loss is very low).

Fortunately, the problem that this draft purports to solve is real and well-described - so it seems that a solution is needed.  Section 3.2 of the draft does, in fact, describe an existing solution - “multicast-ABR” - that does include a (NORM-based) protocol for reliable delivery.  The draft makes three arguments against using this existing solution, but only the first of these arguments (the lack of a ‘fast channel switching’ mechanism (e.g., RFC 6285)) seems strong.  The other two arguments seem rather weak, specifically:
	- "some telecom operators only have IPTV multicast platform, which may not support NORM protocol”
		True, but providing reliable delivery using a RTP-based solution will likely also require a more extensive use of the RTP protocol than IPTV platforms already provide - so some extra implementation would be required in either case.
	- "NORM is not aware of the media timing in a way that RTP is as RTP is nature to handle multimedia”
		I’m not quite sure what this means, but I note that the proposed RTP payload doesn’t have much ‘awareness’ of media timing either.  In particular, the draft proposes using the same RTP timestamp for all RTP packets that make up a single media segment.
(I can’t help but wonder if there might be some unstated ‘hidden agenda’ for not wanting to use the “multicast-ABR” mechanism...)

Some additional quick comments:

- Section 4: "HAS Over RTP Use Scenarios”
This section notes that “With the introduction of HAS payload for RTP, network operators can reuse the existing [IPTV] infrastructure”.  Once again, this argument seems to discount the fact that - to guarantee reliable delivery - existing IPTV networks will require some extra implementation.

- Section 6.3: "Manifest file and Initial Information Consideration”
This section seems very vague about whether or not the ‘manifest files’ are needed to be delivered, and, if so, how they would be delivered (‘out of band’).  If this draft were to be adopted as a Working Group item, then it would (IMHO) need to be a lot clearer about exactly what would need to be implemented here.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 7 Dec 2016 09:01:57 +0000

Hi Ross,

Thanks for your comments. Please see inline.

BR,
Rachel

-----邮件原件-----
发件人: payload [mailto:[email-masked]] 代表 Ross Finlayson
发送时间: 2016年12月7日 8:31
收件人: [email-masked]
主题: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document

[Rachel]: We are targeting the scenario that video doesn't have to be delivered reliably. If you want video to be reliable, RTP may not be the good choice. But video transport doesn't have to  be so reliable? Video is reliable only because video is transported by HTTP to the end user, not because video transport requires 100 percent reliability. And also it's live video, delay is more critical than reliability. So in this draft, the scenarios is very clear, that video is transported by multicast to the end users who are able to directly join the multicast group, e.g., STB, or the end users who are capable of parsing the RTP protocol and the payload, e.g., an APP in mobile phone. We're not targeting the end users that using HTTP to receive the live video, so I think reliability is not mandated. Of course, if some packets are very important, e.g., the packet containing I frame, they can be retransmitted by the methods specified in current RTP technologies like FEC or retransmission. It makes sense to sacrifice some reliability to reduce the delay and increase the throughput.

[Rachel]: Current IPTV providers already implement the mechanisms like retransmission or FEC to protect important packets. They are existing technologies that are being used. 

[Rachel]: This can be discussed. I'm not saying that current RTP timestamp in this draft is the most reasonable setting. People can certainly have better ideas. What we were saying is that RTP is born to handle multimedia things. It has a lot of features that are suitable for delivering media. While, NORM is designed for delivering files, and cannot be well supported by end users. It needs something to convert the multicast NORM to unicast HTTP, which means the M2U devices act as both the multicast client and HTTP proxy. For real implementation, the M2U, which can be a ONT or OLT, will be very complex and be difficult to serve as many as possible channels and end users due to the limited storage and CPU capabilities.

[Rachel]: See above.

[Rachel]: In has over RTP, it's a PUSH mode instead of the PUSH mode that HTTP streaming is using. Media is push from the server to the receiver and the receiver will not ask for each segments, which means the receivers don't rely so much on the manifest files as the HAS does. So manifest files are not delivered in the media path, instead, it can be signaled by HTTP or SDP, or even not required.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 7 Dec 2016 11:32:14 +0100

Hi,

I have reviewed the updated draft and think this call for adoption 
should be postponed a bit until the scope of the work has been 
clarified. I find several significant uncertainties in the description 
in the draft making the use and thus scope of the solution unclear.

First, what are the actual intended usage, and especially what 
termination points are intended? Section 5 discusses both direct 
multicast RTP consumers of the media content. I would guess that 
includes existing Set top boxes (STB). The other set of receivers 
appears to be unicast devices in a LAN behind a gateway, for example the 
operators Customer Premise Equipment (CPE). But still deliver RTP to the 
unicast receiver.

I don't quite see how these purpose matches the proposed format. So the 
media content for HAS has different formats, but the HTTP retrieved 
media segments are to my understanding predominately either MPEG 
Transport Stream formats, or an ISO Base Media File Format based file 
format. The MPEG TS is something that the IPTV STB commonly already 
handles, assuming the right set of codecs in the TS. The ISOBMFF file 
fragment i don't see how that is suitable to include over RTP at all 
towards RTP receivers. If the use case is to use the IPTV RTP multicast 
transport as a way to get the data to the CPE, and then re-assembly the 
file and serve from the CPE to unicast device over HTTP then it makes 
some sense. Except that RTP may not be the most efficient file transport 
protocol, considering its intention to rather handle losses gracefully.

So from my perspective the proposed format seems a poor match to meet 
the goals that has been expressed. Thus, I would like to request that 
the use cases and goals of the work is clarified before we start work on 
a solution in this WG.

I also have to remark that I find it strange that the proposed solution 
with a payload has a parameter that indicate the format of the MPD, i.e. 
HLS or DASH, rather than indicate the actual media format, i.e. MPEG TS 
or what type of ISOBMFF, that is included in the payloads.

I would also note that the security requirements of this solution needs 
to be discussed. It appears that integrity and source authentication are 
important, and I would at least raise the question if one needs to have 
some secured indication of source origin of the media content in some 
way to prove the actual origin of the media content?

The congestion control section also looks contradicting the earlier 
section on multicast ABR. In HTTP adaptive streaming the ABR part is 
there to adopt to the long term capacity of the network path, where TCP 
performs congestion control and probes for the current throughput. In a 
multicast network, where this text appear to indicate that congestion 
control is not needed because of known resource, what is the role of 
having multiple bit-rates made available?

Can we please have these issues resolved before adopting the draft?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Wed, 7 Dec 2016 17:14:23 +0000

Hi,

> On 7 Dec 2016, at 10:32, Magnus Westerlund <[email-masked]> wrote:
> 
> I have reviewed the updated draft and think this call for adoption should be postponed a bit until the scope of the work has been clarified. I find several significant uncertainties in the description in the draft making the use and thus scope of the solution unclear.
> 
> First, what are the actual intended usage, and especially what termination points are intended? Section 5 discusses both direct multicast RTP consumers of the media content. I would guess that includes existing Set top boxes (STB). The other set of receivers appears to be unicast devices in a LAN behind a gateway, for example the operators Customer Premise Equipment (CPE). But still deliver RTP to the unicast receiver.

My impression is that this only makes sense if RTP is being delivered to the receiver. If you want to gateway HTTP to multicast and back to HTTP, then some form of reliable multicast is needed.

> I don't quite see how these purpose matches the proposed format. So the media content for HAS has different formats, but the HTTP retrieved media segments are to my understanding predominately either MPEG Transport Stream formats, or an ISO Base Media File Format based file format. The MPEG TS is something that the IPTV STB commonly already handles, assuming the right set of codecs in the TS.

Fragmenting an MPEG TS into RTP packets clearly makes sense. Whether it makes sense to use this new format, or convert to the existing MPEG payload format is an open question. 

> The ISOBMFF file fragment i don't see how that is suitable to include over RTP at all towards RTP receivers. If the use case is to use the IPTV RTP multicast transport as a way to get the data to the CPE, and then re-assembly the file and serve from the CPE to unicast device over HTTP then it makes some sense. Except that RTP may not be the most efficient file transport protocol, considering its intention to rather handle losses gracefully.

Particular profiles of the ISO file format could make sense, presumably, if fragmented carefully into RTP packets, and if the receiver were aware that some data might be lost. The draft should certainly discuss this further. Indeed, my biggest concerns with this draft are getting the scope correct, so it’s clear what type of HTTP adaptive streaming content can be delivered over RTP, and what are the implications of unreliable delivery of that content. It would be good if the draft could walk through the details of how to packetise the content, at least in outline, to show that it can be done in a manner that allows receivers to make use of the received packets, even if there is loss (i.e., the usual ALF argument).

> So from my perspective the proposed format seems a poor match to meet the goals that has been expressed. Thus, I would like to request that the use cases and goals of the work is clarified before we start work on a solution in this WG.
> 
> I also have to remark that I find it strange that the proposed solution with a payload has a parameter that indicate the format of the MPD, i.e. HLS or DASH, rather than indicate the actual media format, i.e. MPEG TS or what type of ISOBMFF, that is included in the payloads.

The media format should certainly be signalled, although it can likely go into SDP. Is the MPD format (and URL) needed in case the receiver wants to use HTTP to replace lost RTP packets on the multicast group? 

> I would also note that the security requirements of this solution needs to be discussed. It appears that integrity and source authentication are important,

Yes, but presumably no more than for any other RTP payload format specification?

> and I would at least raise the question if one needs to have some secured indication of source origin of the media content in some way to prove the actual origin of the media content?

Seems worth discussing.

> The congestion control section also looks contradicting the earlier section on multicast ABR. In HTTP adaptive streaming the ABR part is there to adopt to the long term capacity of the network path, where TCP performs congestion control and probes for the current throughput. In a multicast network, where this text appear to indicate that congestion control is not needed because of known resource, what is the role of having multiple bit-rates made available?

The gateway would presumably fetch multiple quality levels, and send each on a different multicast group, allowing the receivers to choose an appropriate level. This should be discussed, I agree.

> Can we please have these issues resolved before adopting the draft?

Cheers,
Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: "Roni Even" <[email-masked]>
Date: Wed, 7 Dec 2016 22:56:04 +0200

Hi Magnus,
I think that the motivation for this payload is the case for real time
streaming. There are two different types of applications in the streaming
world. The first one is using prerecorded content and users are accessing it
in a non-synchronize way, this may look more like file access on a server .
The second is an event that is happing now viewed by multiple users all of
them watching the same content at the same time, this is more a real-time
broadcast type of content delivery. This payload and solution is for this
second case where it make more sense to push the content to the receivers
and use multicast (single source multicast) to deliver the content using
less network resources. My understanding that using RTP here to carry the
content that can also be available with HTTP provides better scaling for
delivering this content to a large number of concurrent users. Better having
STB supporting multicast. Using RTP allows also for fast channel switch,
like switching from one football game to another played at the same time
(UEFA Champions League)
The issue of reliability need to be discussed but as the motivation is for a
service that cost money, the first reliability point will be by allocation
of network resources to allow for better QoS, still other means defined for
RTP (retransmission (maybe with fast synchronize) and FEC) is needed (you do
not want to miss a goal in a football match).

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2016 12:32 PM
> To: Roni Even; [email-masked]
> Cc: Ali C. Begen
> Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as
a
> payload WG document
> 
> Hi,
> 
> I have reviewed the updated draft and think this call for adoption should
be
> postponed a bit until the scope of the work has been clarified. I find
several
> significant uncertainties in the description in the draft making the use
and
> thus scope of the solution unclear.
> 
> First, what are the actual intended usage, and especially what termination
> points are intended? Section 5 discusses both direct multicast RTP
consumers
> of the media content. I would guess that includes existing Set top boxes
> (STB). The other set of receivers appears to be unicast devices in a LAN
> behind a gateway, for example the operators Customer Premise Equipment
> (CPE). But still deliver RTP to the unicast receiver.
> 
> media content for HAS has different formats, but the HTTP retrieved media
> segments are to my understanding predominately either MPEG Transport
> Stream formats, or an ISO Base Media File Format based file format. The
> MPEG TS is something that the IPTV STB commonly already handles,
> assuming the right set of codecs in the TS. The ISOBMFF file fragment i
don't
> see how that is suitable to include over RTP at all towards RTP receivers.
If
> the use case is to use the IPTV RTP multicast transport as a way to get
the
> data to the CPE, and then re-assembly the file and serve from the CPE to
> unicast device over HTTP then it makes some sense. Except that RTP may not
> be the most efficient file transport protocol, considering its intention
to
> rather handle losses gracefully.
> 
> the goals that has been expressed. Thus, I would like to request that the
use
> cases and goals of the work is clarified before we start work on a
solution in
> this WG.
with a
> payload has a parameter that indicate the format of the MPD, i.e.
> HLS or DASH, rather than indicate the actual media format, i.e. MPEG TS or
> what type of ISOBMFF, that is included in the payloads.
> 
> I would also note that the security requirements of this solution needs to
be
> discussed. It appears that integrity and source authentication are
important,
> and I would at least raise the question if one needs to have some secured
> indication of source origin of the media content in some way to prove the
> actual origin of the media content?
> 
section on
> multicast ABR. In HTTP adaptive streaming the ABR part is there to adopt
to
> the long term capacity of the network path, where TCP performs congestion
> control and probes for the current throughput. In a multicast network,
where
> this text appear to indicate that congestion control is not needed because
of
> known resource, what is the role of having multiple bit-rates made
available?

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 8 Dec 2016 10:17:58 +0100

Hi,

Yes, I do understand that the main use case for this format is for Live 
broad casts that has many simultaneous viewers. What I think the draft 
fails at currently is to make clear which are the main use cases and 
what are the assumptions of the receiver capabilities. Because I think 
the real devil here is in the media formats used in the media fragments 
the adaptive HTTP streaming service uses. There is both multiple formats 
and multiple codecs. There are also varying parameterizations of the 
encoding.

Regarding the fast channel switch, so the intention here is to use a 
RAMS type functionality, and then have the HAS RTP stream be 
sufficiently marked to indicate where the IRAP's in the video are so 
that the RAMS sender can burst from that position? I note that the 
possibility for the HAS RTP gateway to perform this is depending on the 
meta data in the media fragment if the content is DRM protected.

I really want the main use cases and assumptions to be clearly specified 
in the draft, before the decision of WG adoption is taken. I do see some 
potential in this area, but I do want it to be clearer what is intended 
to be done before supporting it.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 8 Dec 2016 09:30:01 +0000

Hi,

BR,
Rachel

> From: payload [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, December 08, 2016 1:14 AM
> To: Magnus Westerlund
> Cc: Ali C. Begen; [email-masked]
> Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a
> payload WG document
> 
> Hi,
> 
> > I have reviewed the updated draft and think this call for adoption should be
> postponed a bit until the scope of the work has been clarified. I find several
> significant uncertainties in the description in the draft making the use and thus
> scope of the solution unclear.
> >
> points are intended? Section 5 discusses both direct multicast RTP consumers
> of the media content. I would guess that includes existing Set top boxes (STB).
> The other set of receivers appears to be unicast devices in a LAN behind a
> gateway, for example the operators Customer Premise Equipment (CPE). But
> still deliver RTP to the unicast receiver.
> 
> My impression is that this only makes sense if RTP is being delivered to the
> receiver. If you want to gateway HTTP to multicast and back to HTTP, then
> some form of reliable multicast is needed.

[Rachel]: Yes. The traditional way is to convert multicast to unicast in HTTP. However, we're targeting the live HTTP streaming services. It's really difficult to implement in CPE devices considering current capability and resources of such devices. It's better to be a server rather than a network device to do such kind of work. And if supporting 4K live or future VR live, the issue could be severe. But if unicast to end users by RTP, things could be very simple, M2U could be just a RTP translator which doesn't require too much processing.

> Stream formats, or an ISO Base Media File Format based file format. The MPEG
> TS is something that the IPTV STB commonly already handles, assuming the
> right set of codecs in the TS.
> 
> Fragmenting an MPEG TS into RTP packets clearly makes sense. Whether it
> makes sense to use this new format, or convert to the existing MPEG payload
> format is an open question.
> 
> > The ISOBMFF file fragment i don't see how that is suitable to include over RTP
> at all towards RTP receivers. If the use case is to use the IPTV RTP multicast
> transport as a way to get the data to the CPE, and then re-assembly the file
> and serve from the CPE to unicast device over HTTP then it makes some sense.
> Except that RTP may not be the most efficient file transport protocol,
> considering its intention to rather handle losses gracefully.
> 
> Particular profiles of the ISO file format could make sense, presumably, if
> fragmented carefully into RTP packets, and if the receiver were aware that
> some data might be lost. The draft should certainly discuss this further. Indeed,
> my biggest concerns with this draft are getting the scope correct, so it's clear
> what type of HTTP adaptive streaming content can be delivered over RTP, and
> what are the implications of unreliable delivery of that content. It would be
> good if the draft could walk through the details of how to packetise the content,
> at least in outline, to show that it can be done in a manner that allows
> receivers to make use of the received packets, even if there is loss (i.e., the
> usual ALF argument).

[Rachel]: Okay, I think we do lack such discussion in current draft.

> the goals that has been expressed. Thus, I would like to request that the use
> cases and goals of the work is clarified before we start work on a solution in
> this WG.
> >
> > I also have to remark that I find it strange that the proposed solution with a
> payload has a parameter that indicate the format of the MPD, i.e. HLS or DASH,
> rather than indicate the actual media format, i.e. MPEG TS or what type of
> ISOBMFF, that is included in the payloads.

[Rachel]: The consideration is to let multicast gateway as simple as possible. Instead of analyzing the media segment to convert to different payload format, it's more simple to just encapsulate in a common format and won't break the end to end encryption mechanism.

> 
> The media format should certainly be signalled, although it can likely go into
> SDP. Is the MPD format (and URL) needed in case the receiver wants to use
> HTTP to replace lost RTP packets on the multicast group?

[Rachel]: I think so. But MPD files could be transported in out of band ways.

> 
> > I would also note that the security requirements of this solution needs to be
> discussed. It appears that integrity and source authentication are important,
> 
> indication of source origin of the media content in some way to prove the actual
> origin of the media content?
> 
> Seems worth discussing.
> 
> > The congestion control section also looks contradicting the earlier section on
> multicast ABR. In HTTP adaptive streaming the ABR part is there to adopt to
> control and probes for the current throughput. In a multicast network, where
> this text appear to indicate that congestion control is not needed because of
> known resource, what is the role of having multiple bit-rates made available?
> 
> The gateway would presumably fetch multiple quality levels, and send each on
> a different multicast group, allowing the receivers to choose an appropriate
> level. This should be discussed, I agree.

[Rachel]: Exactly. It's quite different from DASH. The scenario is that when M2U serving multiple devices, e.g., mobile phone, and TV. The TV could request the 4K live content, while the mobile phone could just request the 720p resolution.

---

From: Thomas Edwards <[email-masked]>
Date: Thu, 8 Dec 2016 19:23:58 +0000

On 12/8/16, 1:30 AM, "payload on behalf of Huangyihong (Rachel)" <[email-masked] on behalf of [email-masked]> wrote:

>  [Rachel]: Yes. The traditional way is to convert multicast to unicast in HTTP. However, we're targeting the live HTTP streaming services. It's really difficult to implement in CPE devices considering current
> capability and resources of such devices.

It should be noted that the Dyle Mobile TV service in the US developed a solution that ran on iPhones to take multicast RTP packets (from a mobile DTV receiver dongle), and then in software on the iPhone converted those multicast RTP packets into unicast HTTP delivered HLS for playback via the iOS HLS API.  

-Thomas

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 08 Dec 2016 14:44:18 -0600

Out of curiosity, has there been any discussion between the authors of 
this draft and the people interested in GGIE (Glass-to-Glass Internet 
Ecosystem) at W3C, and as was discussed at the DISPATCH meeting in 
Berlin?

I recognize this is talking about live content, and so far GGIE has 
mainly talked about stored content. But it still might be interesting to 
see if there are intersections in the use cases.

Thanks!

Ben.

On 22 Nov 2016, at 6:50, Roni Even wrote:

> Hi,
>
> This is a call to adopt draft-wei-payload-has-over-rtp-01 as a Payload 
> WG
> document and create a milestone for this
>
> There was already support to adopt it in  the payload session at 
> IETF97 and
> this email is to verify the support
>
>
>
> Thanks
> Roni Even
> Payload co-chair

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 9 Dec 2016 08:38:56 +0000

Yes, I’ve talked to them. I think GGIE is kind like ICN except they want to use IPv6 address to name the content. The benefit is that it can still use current network routing mechanisms. And we share the same view that video is dominating the network and could be a big problem in the future when 4K or 8K video is prevalent. GGIE and our has over RTP go for two different directions. GGIE wants to use new content distribution method. Has over RTP intends to use multicast to solve the explosion of the live video traffic.

BR,
Rachel

From: payload [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Friday, December 09, 2016 4:44 AM
To: Roni Even
Cc: Ali C. Begen; [email-masked]
Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document

Out of curiosity, has there been any discussion between the authors of this draft and the people interested in GGIE (Glass-to-Glass Internet Ecosystem) at W3C, and as was discussed at the DISPATCH meeting in Berlin?

I recognize this is talking about live content, and so far GGIE has mainly talked about stored content. But it still might be interesting to see if there are intersections in the use cases.

Thanks!

Ben.

Hi,

There was already support to adopt it in  the payload session at IETF97 and this email is to verify the support

Thanks

Roni Even

Payload co-chair

_______________________________________________
payload mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/payload